[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 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.


 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

        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.

 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: