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

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


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

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


- -- 
 Everything happens at the same time with nothing in between.  -- Paul
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
Version: GnuPG v1.0.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>


Reply to: