Re: Process is no substitute for understanding
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.
For example, you'd be happy if the quality of work done by the Debian
policy group was comparable to that of the people who did C9X ? That
is, the new C standard, whose authors didn't even read the GCC
manual ?
IETF working groups are perhaps a better example. However, they do
_not_ have a formal procedure for deciding what goes into the spec or
not; instead, the working group chair decides when there is `rough
consensus'. Also, it's more important that an IETF working group not
be dependent on the excellence of a few individuals because the
remedial processes for bad decisions are so much worse.
> Indeed, this paragraph above demonstrates the flaws in the
> position that Ian holds: It cncentrates power into very few hands,
> and even though the power is not absolute, we all know how the last
> policy czar position ended.
The whole way we organise the distribution concentrates power over
things into the hands of those who do them - package maintainers !
This is good because the people who do something are the people who
know about it and are most likely to make the right decisions.
When the last policy czar quit the technical committee didn't exist -
ie, there was no appeal mechanism, so that they had to make all the
final decisions with `like it or lump it' pronouncements. Now the
policy editor would be able to say `if you don't like it, go to the
technical committee' - after all, that's what they're there for.
> 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.
So have a couple of people, or allow NMUs just like any other package
to fix urgent problems ?
We already have mechanisms for handling temporarily or permanently
absent maintainers. In this case there'd be another mechanism too -
the project leader could appoint a standin.
> 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.
Yes, I do believe in the fundamental correctness of elitism in Debian:
decisions should be made by people who are both intelligent, and
knowledgeable about the matter at hand. It is not the case that all
our developers have the same level of skill - surely you do not
dispute this ?
> > As a couple of examples, the bug I reopened at the start of this
> > flamewar falls into the category (b), and the decision to change the
> > reference to the FSSTND to a reference to the FHS, without writing a
> > transition plan, is a case of (a).
>
> Seems to me that most technically excellent people weren't
> paying attention for (a), and thus making any one of the technically
> excellent people a policy editor is fraught to failure since you
> can't force a volunteer to work, or perhaps (a) was harder than first
> envisaged?
Changing the policy manual like that was a failure of the policy
process, as well as a simple mistake. It was a very significant
change, and there should have been _something_ to make sure that it
was properly thought through.
You, as policy editor, weren't that something. Relying on a mailing
list to come up with objections every time something disastrous is
proposed is a very bad idea.
If nothing else, the current state of the policy process is very
frustrating to work with. To get seemingly simple and obvious changes
through you have to grind the handle on a tedious bureaucracy;
proposals which some weenie doesn't understand can get stalled
indefinitely until you convince them; early-stage ideas which need
lots of discussion get bogged down in procedural detail too early,
because they don't fit what most of the rest of the traffic on the
list is like; and, inattention for a while on the part of the best -
and busiest - people in the project will allow bad or even disastrous
changes through on the nod.
This is not a rewarding environment.
> Unstable breaks. And the work put i by people would have been
> required in any case to move to the FHS in any case -- and we need to
> move to the FHS to retain compatibilty with the rest of Linux
> community. Retaining compatibility is vital to the viability of
> Debian.
I'm not arguing against (eg) /usr/share. However, the lack of a
transition plan has meant that it's not possible to mix and match
packages from stable and what is now frozen. When frozen is released
as the new stable, incremental upgrades will not work properly.
> 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.
There were other ways to change that, for example by editing dpkg
yourself. However, I think that you're looking at the wrong point in
the process: you seem to be talking about what happened when the
mistake was discovered and eventually it had to go to the technical
committee.
I'm talking about the change that was made in the first place. When
the FSSTND to FHS change was made noone went through the two
standards, enumerated the differences, and figured out whether and how
to get from A to B in each case. This was clearly essential, but it
wasn't done and the result has been a lot of grief.
> > 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.
The policy czar process was working very well until flameage, and lack
of a proper appeal process, made the policy czar feel their position
was untenable.
> > Maintainers of packages which by their position effectively set
> > standards for other packages should not have to come here and engage
> > in a complex and bureaucratic process in order to document the
> > behaviour of their software !
>
> This is wrong headed. The manitainers of those pacjages should
> conform to policy, and they can't, or will not, then we should look
> for a package that shall. The tyranny of monopolistic package
> managers has stifled the project in the past, and we should get away
> from it.
I think we're never going to agree here.
Ian.
Reply to: