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

Re: Bug#97755: PROPOSAL] eliminating task packages; new task system

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

> 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?



Reply to: