On Fri, Oct 27, 2006 at 07:57:20AM -0500, Manoj Srivastava wrote: > > 10:23 <aj> Manoj: will you be following the policy change procedure > > you created > > years ago? (file a bug marked wishlist with the changes > > you want, get a second on the -policy list, answer any > > comments, etc) > > 10:23 <Manoj> aj: nope. that is for others to tell me what to do. > Quite so. As I have explained already in another mailing list, > the policy process document is to ensure that the policy delegates do > not miss out on a proopsal or the discussion around it; it ensures > that I do not drop anything. Since I am driving thids review, there > is no need for me to do the BTS dance. The technical committee charter and the policy process both adopt the principle that the people making the change (the committee members and the policy editors respectively) only act in an editorial capacity -- reviewing changes and committing them appropriately, but not do actual design work in their formal hats. That doesn't mean they can't do design work, just that if/when they do, they're expected to follow the same process anyone else would. AFAICS, that's got multiple benefits -- it means that the priveleges those people get over other developers are minor, it makes it easy for anyone to follow changes because all changes go through the same process, and it provides a consistent process which makes it simpler for everyone to deal with. You said on IRC yesterday that you'd consider treating the current discussion as pre-proposal stuff, and follow the proper process once a conclusion was reached -- that sounds fine to me, but continually reserving the right not to do the "BTS dance" doesn't. If the process isn't suitable for the policy editors, it should be changed for everyone, rather than a short cut setup for the delegates/editors/ctte. > > I'm not willing to let a delegation stand while if it's being used > > as a justification to not talk to other people; even if that's > > happening only hypothetically. > You do not have to justify your decisions to me, but I think > it is evident to anyone who reads the orc log that has been floating > around that I came into that discussion ranting about the release > policy, and said: Sure. But seriously, even ranting on IRC, having delegates repeatedly claim special priveleges to not need to consult with anyone else is beyond the pale for me. Even if you only talk about it but don't act on it, it sets up a precedent for other people to say "well it was okay for him, why not for me?" later. If that's not your view -- and I would have thought it wasn't -- I'd be happy to renew the delegation, but so far you haven't clearly said that. (Personally, I'd rather have an additional three-seven people to delegate too; but I'm afraid I don't have any brilliant ideas on who that could be) > Note that the stated goal was to make policy match the release > criteria: and the commentary was more a reflection of my opinion of > the release policy than anything else. (I should apologize to ABA and > Steve; on closer inspection, the release policy is quite sane). > I now realize that this must also have angered you, since the > release policy has its genesis in something you created. So I > apologize to you, too, for denigrating something you created. Thankyou, that's very gentlemanly. I said this on IRC yesterday, but I'll repeat it here: in spite of any disagreements we have, I think you do a good job both as secretary and policy maintainer -- and in particular in removing the delegation I'd expected you to be able to continue working on it in the same way you had done prior to the delegation. Your weird perl one-liners on IRC were one of the things that attracted me to Debian in the first place, and while I certainly put you in the "crusty, irascible, cantankerous old person full of stubborn ideas" box, I *like* Debian's curmudgeons... Cheers, aj
Attachment:
signature.asc
Description: Digital signature