On Mon, May 21, 2001 at 07:24:35PM -0400, Raul Miller wrote: > > But, basically, you don't need to waste time getting permission for doing > > this: if it's the right thing to do (and a superficial study seems to > > indicate that it is) just go ahead and do it.
On Tue, May 22, 2001 at 09:48:32AM +1000, Anthony Towns wrote: > Well, discussing it on -policy has already introduced a fairly significant > change. So, it doesn't seem like it's a waste of time in that sense. I agree: discussing this on -policy has probably not been a waste of time. > Personally, I'd've thought policy was the exact list to discuss this > on and get consensus: it's implementation of a technical change that > effects a number of packages and has a real need to be documented (since > not having it documented has caused all sorts of tasks to be created which > shouldn't be tasks). Er.. except for one message from Joey (on May 7) I don't see any interaction with the author of tasksel. Personally, I'd consider that sort of interaction extremely valuable for this sort of thing. > I've been hoping to use policy as a canonical list of things packages > are required to do to be released for woody, too. That was the whole > MUST/SHOULD/MAY thing. And it seems like an ideal thing for policy to be > doing: where better to put technical requirements for Debian packages? I don't think that you should ever consider policy to completely cover all release issues. Use it as a checklist, certainly, but its value comes from its stability -- making last minute changes to policy makes about as much sense for the release as making last minute changes to the kernel interface. That said, Manoj has suggested tagging this proposed policy change with [HOLDING], so we don't lose track of it. > I'm amazed that -policy is (has become?) so arduous for such things. > I'm amazed that people would rather give up on working out a consensus > and just have me dictate whatever I think. I'm fairly sure that's > not how things worked when I joined. I'm fairly sure the old way was > better. Eventually I'll probably troll the archives and see if I can > make up some statistics to see. Honestly, do you think that your proposal should not be changed during implementation? You're our release manager -- you're the last person I'd expect to want to be changing the ground rules for debian at the last minute. Think about it: if you force this through policy AND require that all prior policy be canceled, so that all effected packages must follow this new policy, you'll be forcing a policy review of every package in debian -- with attendant changes. So that can't be what you want. If [as you seem to be indicating now] you just want a reference document, then it's perfectly reasonable for you to have your own "woody release plan". And then, once woody is released, and we've had some experience with it, we can say that "this part of the plan was good" and "this part wasn't so hot", and start folding things into policy. > Should I (do I have to?) fork policy and have a > "ajs-official-release-policy-and-errata.deb" or something? I would > like to have a fairly precise (and accurate) list of which bugs > deserve RC bug reports for woody, by the end of next month and random > other policy for the release (eg optional packages not conflicting, > and packages not depending on lower priority packages, and packages > being consistent across architectures and such). Is debian-policy > really unsuitable for that? Basically: debian-policy isn't release oriented. You can use policy in drawing up your plans, but release oriented plans have a different character from policy. [policy is more long-term, while release plans are more immediate.] > If so, what is it suitable for, exactly? It represents those parts of debian which are fairly stable in character, which a package maintainer can rely on in designing a package. It also, to some degree, represents an interpretation of debian's goals. On the other hand, as release manager, you have complete control over the release plans. If you want input from other people: that's great. Does this help? Do you have any substantial disagreements with my understanding? Thanks, -- Raul
