Debian Weekly News - email
To: firstname.lastname@example.org Subject: Re: Process is no substitute for understanding From: Manoj Srivastava <email@example.com> Date: 24 Mar 2000 09:47:03 -0600 >>"Ian" == Ian Jackson <firstname.lastname@example.org> writes: Ian> I think that the fundamental problem is that the policy manual needs Ian> to be coherent and well-thought-out, which means that it needs to be Ian> edited by one or more people who are technically excellent, have the Ian> foresight to anticipate problems, and who are not afraid to put their Ian> own opinions into practice (after discussion, of course). Personally, I don't think 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. Indeed, this paragraph above demonstrates the flaws in the position that Ian holds: It concentrates power into very few hands, and even though the power is not absolute, we all know how the last policy czar position ended. 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 cannot afford to have the whole project dependent one any one person. What Ian denigrates as process and bureaucracy, is merely a mechanism put in place to ensure that no person is named to be in charge of policy all the time -- and that personnel can come in and go away at will. Ian> We must not continue to maintain the policy manual in a way that Ian> means that (a) decisions are be made based on the support of any Ian> few of our (400-odd?) developers - not all of whom are equally Ian> technically excellent - if insufficient people happen to be Ian> around at the time to object; and (b) straightforward and Ian> correct decisions are stalled because either someone who is not Ian> altogether clueful in the area in question doesn't understand it Ian> and objects, or because the work item `fell through the cracks' Ian> and didn't attract enough `me too's. 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. Not there are no problems in the current approach -- we do need a chairman(chairpeople?) to address some of the issues that Ian has raised: a) Have delegated power from the Project leader to over ride the ``clueless'' objections b) Move stalled discussions along by breaking deadlocks, c) create a periodic report of the state of the policy to keep interest alive. d) Sweep through the so called unsexy proposals. Ian> As a couple of examples, the bug I reopened at the start of this Ian> flamewar falls into the category (b), and the decision to change the Ian> reference to the FSSTND to a reference to the FHS, without writing a Ian> 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? Ian> That latter decision has cost most people in the project some Ian> time, in some cases a considerable amount of time, and has (by Ian> sucking effort into firefighting that problem instead of doing Ian> useful work) probably done significant technical damage to the Ian> project beyond what is visible (software sometimes not finding Ian> info files or manpages, etc). This is ironic, considering that most of the mess was created since the people who maintain 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. 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 compatibility with the rest of Linux community. Retaining compatibility is vital to the viability of Debian. The assumptions were that the a) The symbolic link issue should not be an insurmountable problem for developers b) Once helper packages were modified, about 60% of the packages should be conformant (assumption: helper package authors are competent) c) People not using helper packages should be cluefull enough to manage a symlink on their own d) not many programs directly look into the doc directory e) people who maintain programs that look into the doc directory were competent to make them look into both places. It seems that the last may not have been as accurate as desired. However, no amount of policy editor excellence would have changed the latter, since we couldn't have hand held all packages through the transition. Ian> We must take control over our key technical standards away from a Ian> 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> As a related issue, I think that we must cease to make the false Ian> dichotomy between `policy' and `manual for core software'. When I don't think it is a false dichotomy. The implementation of a C compiler does not decide the language. Neither should the implementation of the package manager. You seem to have more faith in the people who program dpkg than I have. And since dpkg programmers have changed, and, indeed, there have been numerous NMU's to that package from a large variety of people, I find your position cointradictory here. Further, I have seen the dpkg code. I am underwhelmed by the quality of that code, and that leads me to have even less confidence in the actual technical competence demonstrated therein. This is a personal opinion, but relevant, I think, even tough it sounds rude. If we were not talking about something I consider critical to the project, I would not have brought this up, and I do apologize. I know that is sounds ad hominem, but I am trying to really pass an objective judgement here. Ian> I think that (for example) the maintainer of dpkg should have the Ian> complete authority to write the dpkg programmers' manual, and That is fine. But the dpkg programmers' manual would not be policy, and indeed, dpkg must conform to policy, not the other way around. Ian> that packages should conform to the requirements of that manual. Ian> Maintainers of packages which by their position effectively set Ian> standards for other packages should not have to come here and engage Ian> in a complex and bureaucratic process in order to document the Ian> behaviour of their software ! This is wrong headed. The maintainers of those packages 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. manoj -- History tends to exaggerate. Col. Green, "The Savage Curtain", stardate 5906.4 Manoj Srivastava <email@example.com> <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
To: Ian Jackson <firstname.lastname@example.org>, Wichert Akkerman <email@example.com> Cc: firstname.lastname@example.org Subject: Discussion on IRC about policy From: Manoj Srivastava <email@example.com> Date: 27 Mar 2000 15:08:04 -0600 Hi, Wichert suggested a meeting on IRC, for discussion about -policy. The discussion is open to all comers (irc.debian.org), but may be moderated and read only, on a channel to be decided. Since Wednesday appears to be the earliest time that may work, how about this: Wednesday March 29th 18:00 CET 16:00 GMT 10:00 CDT I must confess I am not sanguine about this. The positions and arguments have been articulated on the mailing list. An irc meet is useful if there is any ambiguity. or possibility of convergence of views. I'm always willing to listen, and participate in a discussion, but I feel that the positions in -policy are far enough apart, and deeply enough entrenched, to mitigate much chance of convergence through an informal chat. I'm willing to be pleasantly surprised. manoj -- Better hope the life-inspector doesn't come around while you have your life in such a mess. Manoj Srivastava <firstname.lastname@example.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
To receive this newsletter weekly in your mailbox, subscribe to the debian-news mailing list.
Back issues of this newsletter are available.
This issue of Debian Weekly News was edited by Joey Hess.