Re: Process is no substitute for understanding
>>"Ian" == Ian Jackson <ian@davenant.greenend.org.uk> writes:
Ian> Manoj Srivastava writes ("Re: Process is no substitute for understanding"):
>> Personally, I don't thik that this is the only way that things
>> need be done. I find most Standards are in fact not created by a few
>> heroic figures; IETF, IEEE, and ISO working groups are not lone
>> ``technically expert'' cowboys. If our policy matches the quality of
>> the documents produced by those bodies, I shall be content.
Ian> For example, you'd be happy if the quality of work done by the Debian
Ian> policy group was comparable to that of the people who did C9X ?
I have not yet purchased C9X, so I can't comment. The
standards I am familair with are the original C standard, created by
the IEEE, and adopted by the ISO, as well as the POSIX standards.
Yes, indeed, I would be happy with those.
Ian> That is, the new C standard, whose authors didn't even read the
Ian> GCC manual ?
Why on earth would they refer to the GCC manual, of all
things? Gcc is a mere implementation, trying to match the standard,
and perhaps buggy. (This question calls into question your
understanding of the standards process, and the significance of
standards documents themselves).
The implementation does not define the standard. The only
influence it may have on the standard is that it represents some
prior art, and I doubt if Doug Gwen, Larry Jones and Chris Torek are
ignorant of the behaviour of Gcc anyway.
Ian> IETF working groups are perhaps a better example. However, they do
Ian> _not_ have a formal procedure for deciding what goes into the spec or
Ian> not; instead, the working group chair decides when there is `rough
Ian> consensus'. Also, it's more important that an IETF working group not
Ian> be dependent on the excellence of a few individuals because the
Ian> remedial processes for bad decisions are so much worse.
I agree that the current process can use a chairman, without
loosing the distributed collaboration embodied in it. I have said so
before.
Ian> The whole way we organise the distribution concentrates power over
Ian> things into the hands of those who do them - package maintainers !
Ian> This is good because the people who do something are the people who
Ian> know about it and are most likely to make the right decisions.
And package maintainers should have control over what affects
their packages. An author of one package must not have total and
absolute control over how other packages are constructed.
Ian> When the last policy czar quit the technical committee didn't exist -
Ian> ie, there was no appeal mechanism, so that they had to make all the
Ian> final decisions with `like it or lump it' pronouncements. Now the
Ian> policy editor would be able to say `if you don't like it, go to the
Ian> technical committee' - after all, that's what they're there for.
I have little trust on the competence of the tech ctte to
actually resolve things, and even in the competence of all members. I
certainly do not trust them as much as this list, which has, for the
most part, been quite competent.
We do have problems -- but the solution does not involve
throwing out the baby with the bath water
>> Secondly, this does not take into account the nature of the
>> project: This is a project run by volunteers, and the demands of the
>> real life job come first for most of us. Even Ian and I have not been
>> around consistently, we can not afford to have the whole project
>> dependent one any one person.
Ian> So have a couple of people, or allow NMUs just like any other package
Ian> to fix urgent problems ?
A couple of people may not be enough. (look at policy
maintianers -- there are 4, plus Julian, and when I am away, policy
BTS shows visible signs of decay.
Naming a few people is not likely to be a scalable solution.
Ian> We already have mechanisms for handling temporarily or permanently
Ian> absent maintainers. In this case there'd be another mechanism too -
Ian> the project leader could appoint a standin.
Really? They are not working.
>> Yes. The current policy process is hard to stomach for someone
>> who believes in the fundamental correctness of elitism. (I mean no
>> offence by that). The current policy process assumes that there the
>> developers on -policy do have the minimal competence required, or
>> that there are enough technically competent people on -policy to make
>> this work.
Ian> Yes, I do believe in the fundamental correctness of elitism in Debian:
Ian> decisions should be made by people who are both intelligent, and
That brings to the forefront who is considered itelligent. I
certainly disagree with you on that. (Incidentally, wisdom maybe a
greateer virtue than inteligence in a policy creation entity).
Ian> knowledgeable about the matter at hand. It is not the case that all
Ian> our developers have the same level of skill - surely you do not
Ian> dispute this ?
Oh, no -- I just think that I disagree with you about who is
most qualified to be the technical head of policy.
Also, I do not thik that centralizing something like policy is
viable as the project grows.
Ian> You, as policy editor, weren't that something. Relying on a mailing
Ian> list to come up with objections every time something disastrous is
Ian> proposed is a very bad idea.
Please don't distort facts. I was never appointed policy
editor, and never grabbed the mantle of one. You can;t tell some one
``you were the prime minister, and I blame you for the irish fiasco''
At that point, I had not more powers than anyone else in the
list (arguably, only the DPL could have intervened). Of course, were
one to nit pick, I guess this mailing list has not power to amend
policy either.
Ian> If nothing else, the current state of the policy process is very
Ian> frustrating to work with.
Then the solution is to work on making the process more
streamlined, while retaining the dewcentralization.
Ian> To get seemingly simple and obvious changes through you have to
Ian> grind the handle on a tedious bureaucracy;
If the matter is really simple and obvious, the process
requires 4 mail messages, and a period of a week or so to go
through. And rarely is it important to get something into policy
faster than that, since packages may change ahead of policy.
So you find 4 mail messages too onerous.
Interesting.
Ian> proposals which some weenie doesn't understand can get stalled
Ian> indefinitely until you convince them; early-stage ideas which
Ian> need
The chairman shall address this issue (we never had the DPL
delegate such authority before, so it was not possible in the past)
Ian> lots of discussion get bogged down in procedural detail too early,
Why is that? I've seen a lot of discussion on the list
(including this one) that has not been tied to the BTS or any
procedural bottlenecks -- seems like you are inventing issues where
noe exist.
Ian> because they don't fit what most of the rest of the traffic on the
Ian> list is like; and, inattention for a while on the part of the best -
Ian> and busiest - people in the project will allow bad or even disastrous
Ian> changes through on the nod.
Rubbish. Start a discussion. file a wishlist bug on the policy
package. You are assured that the wishlist bug shall remain for two
years.
And is you, or nayone else on the mailing list, has not had
the time or the energy to follow up in two years time, what does that
say about the proposal anyway?
Ian> This is not a rewarding environment.
Neither is watching some elitist power-that-be dismiss your
ideas since you are not worthy enough. (that is as much of a
dist5ortion of your proposal as the paragraph above is of mine)
Ian> I'm not arguing against (eg) /usr/share. However, the lack of a
Ian> transition plan has meant that it's not possible to mix and match
Ian> packages from stable and what is now frozen. When frozen is released
Ian> as the new stable, incremental upgrades will not work properly.
You should then look into what was decided on. The transition
plan is in place; and though there may be bugs in implemntation, that
would have been the case no matter what transition plan would have
gone in effect.
If you have actual defects to offer, please detail them, and
suggest what you think is a recovery plan, and not just use inuendo.
>> This is ironic, considering that most of the mess was created
>> since the people who maintian dpkg (whom you want to give absolute
>> power over determining policy) had been neglecting dpkg and the
>> simple solution was deemed impossible, since changes to dpkg seemed
>> to require a snow storm in hell at that point.
Ian> There were other ways to change that, for example by editing dpkg
Ian> yourself.
Something you always resisted.
Ian> However, I think that you're looking at the wrong point in
Ian> the process: you seem to be talking about what happened when the
Ian> mistake was discovered and eventually it had to go to the technical
Ian> committee.
Mistake? The mistake was that there was no real power assigned
to anyone to break hard deadlocks, and that is what we should
be fixing.
Ian> I'm talking about the change that was made in the first place. When
Ian> the FSSTND to FHS change was made noone went through the two
Ian> standards, enumerated the differences, and figured out whether and how
Ian> to get from A to B in each case. This was clearly essential, but it
Ian> wasn't done and the result has been a lot of grief.
Frankly, I thik that the transition plan in place now does
handle the issues involved.
>> > We must take control over our key technical standards away from a
>> > mailing list and give it back to technical experts !
>>
>> I find this kind of eliticism abhorent, and worse, unworkable
>> as the project scales up. We need to decentralize in order to grow,
>> not go back to a failed policy czar process.
Ian> The policy czar process was working very well until flameage, and lack
Ian> of a proper appeal process, made the policy czar feel their position
Ian> was untenable.
Actually, if I recall it, you were involved in the process,
too, and you pointed out that the policy czar was exercising
preference, or jumping the gun and putting into policy something that
weas not decided. In other words, you accused him of abuse of power,
and that may well have precipitated his departure.
I can dredge out the messages if you like.
manoj
--
You will forget that you ever knew me.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: