Bug#97755: PROPOSAL] eliminating task packages; new task system
-----BEGIN PGP SIGNED MESSAGE-----
Hi,
>>"Anthony" == Anthony Towns <ajt@debian.org> writes:
Anthony> Because tasks are an important component of making the
Anthony> installer usable, and they're currently completely broken
Anthony> (in that around half of the existing tasks in sid simply
Anthony> shouldn't be tasks; and the remaining half have
Anthony> documentation bugs, or don't include a quite optimal set of
Anthony> packages, or similar).
I'll take your word that task packages, as they exist now, are
buggy. This, of course, has nothing to do with new policy.
Anthony> Further, the current tasks make it significantly harder to
Anthony> cope with a freeze, since the task package has to be
Anthony> manually fixed and reuploaded
Fine. The old task-packages are broken, you have a replacement
scheme. Fine and dandy. At some point it may even become policy.
>> We can't use policy to bludgeon people into removing their
>> packages; that has to come from agreements reached with authors of
>> the packages themselves, from the DPL, or a general resolution.
Anthony> Tasks need to be fixed by woody.
So? What does this have to do with policy?
Anthony> Thus, all the task-* packages in woody misleading at best, useless
Anthony> at worst.
So? What does this have to do with policy?
Anthony> Thus they ought to get removed before release.
You are the release manager. File the bugs, declare them
release critical, say that the new scheme is golden, and do what you
wish with the release. Arrange with task package authors to withdraw
the packages, or rule that the packages are too buggy to make it into
woody. Do not drag policy into this.
Anthony> If they're not meant to be in woody, we should put this in
Anthony> policy somewhere.
Eh? No. If you want to do it the policy way, you propose the
change, giving a upgrade path. And in woody +1 the may becomes a
should, and in woody +2 the task packages shall go away. Policy is
not a club. Policy is not meant to make all the task packages
suddenly release critical
Anthony> Since policy's meant to be the place where we can discuss
Anthony> technical changes to Debian that affect multiple packages.
I like the techical discussion. We should implement it by
woody + 2, if you want policy to do what it does. Policy changes do
not suddenly make packages have RC bugs.
Anthony> I'm not sure why you think it's not appropriate for policy
Anthony> to be here:
It is. Shall I change the language to have this implemented by
woody + 2? I 'll second the proposal then.
Anthony> this isn't a matter of packages sucking, it's a matter of having a
Anthony> special, reserved name space that needs cleaning up.
And clean up we shall. The timing is where this proposal is
wrong.
>> I have yet to see a reason for rushing into policy something
>> that is a proposed process, and not yet a documentation of tried,
>> stable, and current practice, Obviously, I am missing something.
Anthony> That we're freezing shortly?
That is irrelevant IMHO. Policy has a modus operandi. and not
even the release manager should ram their changes through
Anthony> Cheers,
Anthony> aj, not seeing much evidence of policy being "lightweight"
Policy is not what you think it is, and attempting to use
policy as a club should never be light weight.
Additionally, gentlemen, unless you can come up with technical
reasons why we should waive the way policy works in this special case
(and not the other special cases other people come up with), please
consider this a formal objection to this proposal.
manoj
- --
Everything happens at the same time with nothing in between. -- Paul
Hebig
Manoj Srivastava <srivasta@debian.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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE7B0PKIbrau78kQkwRAXkDAKDfZwn29qtjFFdDFTyP2dHNK22pXwCgqwpU
Gg25yOdjCgu1GoS1wQfvbv0=
=Ro6O
-----END PGP SIGNATURE-----
Reply to: