Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Tue, May 22, 2001 at 08:02:17PM +0100, Julian Gilbey wrote: If you have the time to sit down and do the jobs you've just listed, fantastic, please do it [...] Well, I already have my hands full with release trivia, but there are definitely some things I can do. My concern has been that the main thing I have worked on (the must/should change) has been partially undone essentially behind my back (the couple of shoulds that mysteriously changed to musts); accompanied with the feeling that policy is more focussed on (what I consider) trivia rather than useful stuff, that's not particularly motivating. I agree with all of the above thoughts, but more volunteers are needed to help them get done quickly. Well, considering Manoj's proposal for this way of handling policy presumed four to six policy editors (or maybe more), and we've only got two, that sounds pretty likely. I wouldn't bet on you being able to get another couple of people willing to be full on editors (least of all after I've been flaming y'all on and off for the past couple of months) but maybe we can get a few people doing random things to clean up policy. What're the most important things that need to be done? AFAICS: * Fix up any outright errors in policy (where it tells you to do something you just plain shouldn't; or where it tells you one thing in one place and the opposite somewhere else) * Fix the musts and shoulds (ie change musts that should be shoulds to shoulds and shoulds that should be musts to musts), so -qa can get a handle on what they're doing * Go through all the old proposals and either: + close the report because there's not been any consensus + write a patch and get seconds for the idea + contact whoever should be implementing something and see what's going on * Reword policy so it's more accessible (ie, merge/rearrange sections, change the must/should split to something else) The first two are important for -qa to have some common reference when doing bugsquashes and such during the freeze [0]. The third is probably somewhat important for woody (depending on the particular report) but doesn't need to be completely finished. The fourth can probably wait as long as it needs too; but that would mean the first three shouldn't be delayed until the fourth is finished. Well? Does that make sense? Is anyone else going to have time to do some of this stuff? Cheers, aj [0] During potato's freeze, I spent a *lot* of time recategorizing bug reports since there was no real reference except in my head. So far, with a reference (ie policy's musts) that's written down (even though it's somewhat buggy) I haven't had to do this anywhere near as much. (Which seems due to either submitters reading the reference and getting it right first time, or maintainers/qa reading the reference and being able to fix it themselves) -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpMz5W12qktK.pgp Description: PGP signature
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 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
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Tue, May 22, 2001 at 01:28:08AM -0400, Raul Miller wrote: 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. Randolph's busy doing other things unfortunately (otherwise we'd probably have had a changed implementation ages ago), Joey H and I've been in contact with him privately. 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. Uh, riiight. That analogy is *completely* nonsensical. I'm amazed that -policy is (has become?) so arduous for such things. Honestly, do you think that your proposal should not be changed during implementation? Honestly, I don't think it'll change at all during implementation. The proposal you've got describes the design and barely goes into any detail at all. And if it does change, then we just adjust policy to match. Policy's meant to be a lightweight process, remember. 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. Changing the way tasks are handled has nothing to do with changing the ground rules for debian. It effects, quite literally, 56 packages (55 task packages and tasksel), or about 0.8% of the distro. 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. And again, this policy has *no* effect on packages that aren't named task-something. It doesn't stop people from reuploading their packages with a different name. For most of the tasks, it doesn't stop them from being tasks, at all. 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. Nor need it be. All it has to do is describe what packages in unstable should look like. Seriously, that's all it has to do. It doesn't have to specify what they should look like in five months when some transition or other is completed; it doesn't have to say what they looked like five months ago; just how they should look right now. It doesn't have to be particularly precise about it: we've got the maintainer's judgement, the ftpmasters' judgement, the RM's judgement and the tech ctte's judgement to fall back on if something's not specified quite right. Generally, we don't want to declare what's in unstable as completely wrong right now. So, in general, it's best to be conservative about adding musts. In this case though, we do. Sometimes you need to make exceptions to general rules. That's life. 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. So it's more of an historical document than guidelines for how packages should be built now? (This certainly seems an accurate statement of what policy *is* right now, as opposed to what it should be. Going through the functional changes (ie, ones that influence how packages should be built) from recent policy uploads, we see: * /var/mail / /var/spool/mail: proposed and essentially agreed upon in October 1999, implemented in base-files, finally included in policy in April 2001 (42052) * Perl policy: developed completely separately from policy, implemented by the perl maintainer, and included as a separate document * Debconf: allow the use of debconf, in Jan 2001; well after a release that included debconf in base, a year after that release entered its freeze, and well over that since packages actually used debconf. * Multiple maintainers: allow many people to maintain a package in
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Tue, May 22, 2001 at 01:28:08AM -0400, Raul Miller wrote: 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. On Tue, May 22, 2001 at 09:15:10PM +1000, Anthony Towns wrote: Uh, riiight. That analogy is *completely* nonsensical. I'll grant you that it's not a direct analogy -- changing the kernel interface would immediately break software, while changing policy only makes software non-compliant. However, changing packages to comply with new policy can break the software, might require new policy revisions, etc. I'm amazed that -policy is (has become?) so arduous for such things. Honestly, do you think that your proposal should not be changed during implementation? Honestly, I don't think it'll change at all during implementation. The proposal you've got describes the design and barely goes into any detail at all. And if it does change, then we just adjust policy to match. Policy's meant to be a lightweight process, remember. Actually, I don't remember. Pointer? There's a lot of packages, and many of them have to change to comply with new policy. Which is one of the reasons we don't ask that all developers instantly comply with each policy change. 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. Changing the way tasks are handled has nothing to do with changing the ground rules for debian. It effects, quite literally, 56 packages (55 task packages and tasksel), or about 0.8% of the distro. But policy represents the ground rules for debian. And, if you're going to use policy to express that the tasksel change is important for this release, you're going to be revoking all policy which doesn't have the tasksel change. And that is going to impact a lot more than 56 packages. 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. And again, this policy has *no* effect on packages that aren't named task-something. It doesn't stop people from reuploading their packages with a different name. For most of the tasks, it doesn't stop them from being tasks, at all. All this is relevant if you're speaking from a point of view which doesn't *require* that this policy be actually used before woody is released. Which leads to the question: what is the actual requirement here? 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. Nor need it be. All it has to do is describe what packages in unstable should look like. And it isn't even a complete reflection of that, nor was it ever intended to be. Seriously, that's all it has to do. It doesn't have to specify what they should look like in five months when some transition or other is completed; it doesn't have to say what they looked like five months ago; just how they should look right now. It doesn't have to be particularly precise about it: we've got the maintainer's judgement, the ftpmasters' judgement, the RM's judgement and the tech ctte's judgement to fall back on if something's not specified quite right. Uh.. but disagreements on these things can be unpleasant to resolve. Anyways, I don't think it's worthwhile arguing from the point of view that expects all maintainers to disagree with policy where needed. Generally, we don't want to declare what's in unstable as completely wrong right now. So, in general, it's best to be conservative about adding musts. In this case though, we do. Sometimes you need to make exceptions to general rules. That's life. That's great, but it's still not at all clear what the requirement is, here. [See above. If you've refuted my points about policy release management and how policy is used, that would refute this point as well.] 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. So it's more of an historical document than guidelines
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
You are the release manager. File the bugs, declare them release critical [...] Anthony Towns wrote: Okay. Whatever. I really don't have the patience for -policy anymore. On Sun, May 20, 2001 at 10:17:48PM -0400, Joey Hess wrote: You know, neither do I. Manoj, have fun waiting until woody + 2 or whenever you want and then documenting something that happened 2 years prior.. That's what change logs are for. Perhaps there should be a release-oriented changelog? It does seem reasonable that we should have some sort of queuing mechanism to park proposed policy changes as they're tried out, but arguably, change logs could suffice for that as well. -- Raul
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Sun, 20 May 2001, Anthony Towns wrote: You are the release manager. File the bugs, declare them release critical [...] Okay. Whatever. I really don't have the patience for -policy anymore. I agree with Manoj on this. task packages exist potato and woody. That means we have to support an upgrade path from potato to woody(and beyond!). There can not be an abrupt change. That goes against one of debian's main features, upgradability. We are too close to freeze, to have this implemented right, no matter HOW simple the code is. We can maybe support both, with the new way not being in it's final form. It's final form will most likely be adopted sometime in woody+1, with the form in woody probably being close to this. Policy should document this final woody form, and then be modified when the final form comes in to play in woody+1. However, what we have so far, is policy being modified to document the pre-implementation code, not what has already been in use.
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Sun, May 20, 2001 at 11:55:21AM -0500, Adam Heath wrote: On Sun, 20 May 2001, Anthony Towns wrote: You are the release manager. File the bugs, declare them release critical [...] Okay. Whatever. I really don't have the patience for -policy anymore. I agree with Manoj on this. task packages exist potato and woody. That means we have to support an upgrade path from potato to woody(and beyond!). There can not be an abrupt change. Upgrading from potato to woody and beyond works fine, nothing breaks, you merely don't get your tasks to upgrade cleanly by simply using apt. We are too close to freeze, to have this implemented right, no matter HOW simple the code is. Please go back and reread the thread about this immediately after potato's release: the problem with tasks as they existed for potato was that they make it very hard to cope with RC bugs in packages in a task. If any one package has an RC bug and has to be removed, the entire task gets broken. That needs to be resolved before this freeze, no matter how complicated the code is. Since people seem to be more amenable to statements from authority than sensible reasons, take the above as a statement from the release manager. Woody needs tasks, and they need to be fixed compared to potato's implementation and the task packages in woody and sid at present. I would highly appreciate it if people would mind actually helping resolve this than continually harping on about why this can't possibly be done. Additionally, we'll be fixing the optional/extra priority mismatches for woody. It would be nice to also have an up to date list of lintian errors for -qa to work through. It'd be very nice if someone could work through policy and mind anything that's either wrong, or inconsistent (especially as far as shoulds and musts are concerned). As opposed to working out exactly what /bin/sh can be for example. Regards, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgprlUN49cEvz.pgp Description: PGP signature
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Mon, 21 May 2001 18:04:42 +1000 Anthony Towns [EMAIL PROTECTED] wrote: On Sun, May 20, 2001 at 11:55:21AM -0500, Adam Heath wrote: Upgrading from potato to woody and beyond works fine, nothing breaks, you merely don't get your tasks to upgrade cleanly by simply using apt. Isn't that generally considered breakage? We are too close to freeze, to have this implemented right, no matter HOW simple the code is. Please go back and reread the thread about this immediately after potato's release: the problem with tasks as they existed for potato was that they make it very hard to cope with RC bugs in packages in a task. If any one package has an RC bug and has to be removed, the entire task gets broken. Why not simply remove one of the packages from the task if need be? (Forgive my idiocy; I haven't been watching this thread.) Since people seem to be more amenable to statements from authority than sensible reasons... Sadly, that's how American sheeple generally are. And yes, I am American myself, unfortunately... Regards, Alex. pgpJXDuCrXNlQ.pgp Description: PGP signature
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Mon, May 21, 2001 at 01:10:41AM -0700, Alexander Hvostov wrote: On Sun, May 20, 2001 at 11:55:21AM -0500, Adam Heath wrote: Upgrading from potato to woody and beyond works fine, nothing breaks, you merely don't get your tasks to upgrade cleanly by simply using apt. Isn't that generally considered breakage? All the packages in the task upgrade cleanly, the task- package may get removed or it may not, you merely don't get any new packages that might've been added to the task, unless you run tasksel. Of course, if you removed any of the packages in the task since installing potato, the same thing applies, in general. We are too close to freeze, to have this implemented right, no matter HOW simple the code is. Please go back and reread the thread about this immediately after potato's release: the problem with tasks as they existed for potato was that they make it very hard to cope with RC bugs in packages in a task. If any one package has an RC bug and has to be removed, the entire task gets broken. Why not simply remove one of the packages from the task if need be? (Forgive my idiocy; I haven't been watching this thread.) Because that requires contacting the maintainer and nagging him to reupload the task- package, possibly getting it recompiled on all the various arches if it's not arch:all, getting rid of any new bugs that've been introduced, etc. We tried it with potato, it was a pain. Again, see the thread from back in August. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpldKawFEcNG.pgp Description: PGP signature
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Anthony Towns wrote: You are the release manager. File the bugs, declare them release critical [...] Okay. Whatever. I really don't have the patience for -policy anymore. Joey You know, neither do I. Ah. The Things aren't going my way so I'll take the marbles and go home gambit. I am indeed sorry that policy is not a bludgeon to be used on other maintainers, or a means of forcing packages out of a release in a hurry. Indeed, the constitutionality of this policy process has always been a gray area, and were policy to be used as a club, I would think that the process shall be challenged. However, I'd be just as pleased to defer that battle for another day. Convince the task package maintainers. Or get the release manager or the DPL to do so by fiat. Or delay the release until the matter is resolved. The decision is entirely in your hands. Joey Manoj, have fun waiting until woody + 2 or whenever you want Joey and then documenting something that happened 2 years prior.. You are demonstrating a lack of grasp of what policy is here. You see, the moment it becomes existing practice, it can be documented as such in policy. You just can't use policy to force something to be ``existing'' practice when it happens not to be. manoj ps: I leave for New Orleans today, and shall be gone for a week, and may not be able to give folks satisfaction in a pitched flame war, unless they chose to withhold action till I return. -- Joe's sister puts spaghetti in her shoes! Manoj Srivastava [EMAIL PROTECTED] 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
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
Raul == Raul Miller [EMAIL PROTECTED] writes: Raul That's what change logs are for. Perhaps there should be a Raul release-oriented changelog? Raul It does seem reasonable that we should have some sort of Raul queuing mechanism to park proposed policy changes as they're Raul tried out, but arguably, change logs could suffice for that as Raul well. a) We can tag the report [HOLDING] b) We can use the change log, but there is danger held proposals may be lost in the noise c) We can document the practice as soon as it is implemented, and becomes the current practice. manoj -- Facts are the enemy of truth. Don Quixote Manoj Srivastava [EMAIL PROTECTED] 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
Re: Bug#97755: [PROPOSAL] eliminating task packages; new task system
On 19.V.2001 at 11:27 Thomas Bushnell, BSG wrote: Anton Zinoviev [EMAIL PROTECTED] writes: For example what display manager we will choose: gdm, kdm, wdm or xdm? Maybe gdm, because it provides session menu, but it looks to me a little buggy. I'm giving this only as an example. Surely there will be conflicts. What does it mean that gdm looks to [you] a little buggy? Are there bugs you haven't reported? What bugs exactly? It is #82576 and it is not reported by me. My computer uses gdm and after logout sometimes (rarely) gdm dies. But just as the reporter of this bug I don't know when this happens. Anton Zinoviev, [EMAIL PROTECTED]
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
On Mon, May 21, 2001 at 06:04:42PM +1000, Anthony Towns wrote: Please go back and reread the thread about this immediately after potato's release: the problem with tasks as they existed for potato was that they make it very hard to cope with RC bugs in packages in a task. If any one package has an RC bug and has to be removed, the entire task gets broken. That needs to be resolved before this freeze, no matter how complicated the code is. Since people seem to be more amenable to statements from authority than sensible reasons, take the above as a statement from the release manager. Woody needs tasks, and they need to be fixed compared to potato's implementation and the task packages in woody and sid at present. I would highly appreciate it if people would mind actually helping resolve this than continually harping on about why this can't possibly be done. I don't see that people are harping on why this can't possibly be done. I do see people harping on the idea that pushing the design into policy isn't the right way to get it done. As release manager, you (or people acting for you) can already file release critical bugs. Making this policy wouldn't change that in the slightest [unless, you were hoping to cancel all existing valid policy?]. The debian maintainer for tasksel (Randolph Chung) can do all the needed implementation stuff to support your new scheme. If you feel that the current policy forbids this scheme, we could push through a change that ripped out of policy the one phrase where tasks are mentioned. 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. - Raul
Bug#97755: PROPOSAL] eliminating task packages; new task system
-BEGIN PGP SIGNED MESSAGE- Hi, Anthony == Anthony Towns [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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-
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
You are the release manager. File the bugs, declare them release critical [...] Okay. Whatever. I really don't have the patience for -policy anymore. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpbyOXUnzhRY.pgp Description: PGP signature
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
Anthony Towns wrote: You are the release manager. File the bugs, declare them release critical [...] Okay. Whatever. I really don't have the patience for -policy anymore. You know, neither do I. Manoj, have fun waiting until woody + 2 or whenever you want and then documenting something that happened 2 years prior.. -- see shy jo
Re: Bug#97755: [PROPOSAL] eliminating task packages; new task system
On 16.V.2001 at 22:43 Joey Hess wrote: + + p + You should not tag any packages as belonging to a task before + this has been discussed on the `debian-devel' mailing list and + a consensus about doing that has been reached. + /p A consensus is not always possible. Some resolution mechanism is needed in case that there is no consensus. For example what display manager we will choose: gdm, kdm, wdm or xdm? Maybe gdm, because it provides session menu, but it looks to me a little buggy. I'm giving this only as an example. Surely there will be conflicts. Moreover, too many packages have to use the Task field. Do you want a discution for all of them in debian-devel? Is the override mechanism suposed to be only a temporary solution? A maintainer can and may not be aware of the needs of some task. An example: why the maintainer of recode should know that some of the filters of magicfilter needs recode and that magicfilter belongs to the task printing? (Actually I have wrote that again only as an example. If you want I will make ITP of meta-magicfilter, meta-apsfilter and maybe meta-cups. Then one of these three metapackages will belong to the task `Printing'. Or maybe it is better to have more than one task for printing?) Anton Zinoviev, [EMAIL PROTECTED]
Re: Bug#97755: [PROPOSAL] eliminating task packages; new task system
Anton Zinoviev [EMAIL PROTECTED] writes: For example what display manager we will choose: gdm, kdm, wdm or xdm? Maybe gdm, because it provides session menu, but it looks to me a little buggy. I'm giving this only as an example. Surely there will be conflicts. What does it mean that gdm looks to [you] a little buggy? Are there bugs you haven't reported? What bugs exactly?
Re: Bug#97755: [PROPOSAL] eliminating task packages; new task system
On Sat, May 19, 2001 at 07:55:13PM +0300, Anton Zinoviev wrote: A maintainer can and may not be aware of the needs of some task. An example: why the maintainer of recode should know that some of the filters of magicfilter needs recode and that magicfilter belongs to the task printing? Hmm... all along I've assumed that the task selection process will at some point pull in all the dependencies of the selected tasks. Is this the case? Richard Braakman
Bug#97755: PROPOSAL] eliminating task packages; new task system
Hi, Joey == Joey Hess [EMAIL PROTECTED] writes: Mind you, I like the proposal, and were it not for the issue of timing, I would probably have seconded this. Joey It's all about timing, unfortunatly -- we have to get this done before Joey woody base is frozen, and that includes getting the old task packages Joey removed. I think we will though, and will probably have it almostly Joey completly implemented by the time the discussion period is up and it Joey goes into policy. But what's the driving necessity to get this into policy in a hurry? 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. We can then put this all into policy sometime in sarge, after the dust has settled down, and the battle plan has actually made contact with deployment and bug and the myriad strange systems out there. 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. manoj -- You can bear anything if it isn't your own fault. Katharine Fullerton Gerould Manoj Srivastava [EMAIL PROTECTED] 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
Bug#97755: PROPOSAL] eliminating task packages; new task system
On Sat, May 19, 2001 at 03:32:17PM -0500, Manoj Srivastava wrote: But what's the driving necessity to get this into policy in a hurry? Because tasks are an important component of making the installer usable, and they're currently completely broken (in that around half of the existing tasks in sid simply shouldn't be tasks; and the remaining half have documentation bugs, or don't include a quite optimal set of packages, or similar). Further, the current tasks make it significantly harder to cope with a freeze, since the task package has to be manually fixed and reuploaded 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. Tasks need to be fixed by woody. Thus, all the task-* packages in woody misleading at best, useless at worst. Thus they ought to get removed before release. If they're not meant to be in woody, we should put this in policy somewhere. Since policy's meant to be the place where we can discuss technical changes to Debian that affect multiple packages. I'm not sure why you think it's not appropriate for policy to be here: this isn't a matter of packages sucking, it's a matter of having a special, reserved name space that needs cleaning up. 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. That we're freezing shortly? Cheers, aj, not seeing much evidence of policy being lightweight -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Bug#97755: PROPOSAL] eliminating task packages; new task system
Hi Joey! You wrote: After a lot of discussion, AJ and I have settled on a compromise that is acceptable to both of us about what to do to fix Debian's broken[1] task system. snip Looks great to me. I second it. -- Kind regards, +---+ | Bas Zoetekouw | Si l'on sait exactement ce | || que l'on va faire, a quoi| | [EMAIL PROTECTED] | bon le faire?| |[EMAIL PROTECTED] | Pablo Picasso | +---+
Bug#97755: PROPOSAL] eliminating task packages; new task system
On Wed, May 16, 2001 at 10:43:31PM -0400, Joey Hess wrote: After a lot of discussion, AJ and I have settled on a compromise that is acceptable to both of us about what to do to fix Debian's broken[1] task system. imageryDusk. A siren squealing in the distance, maybe police, maybe ambulance, it's hard to tell. An alleyway, damp washing strung above, swaying slightly in the breeze, steam drifting up from a grating, a McDonalds wrapper shuffling past. A body, beaten, bloody, broken, barely gasping for breath. A wrist, slashed. Writing, in the victim's blood, but not by the victim's hand./imagery Seconded. Rather than having task packages any more, individual packages that belong to a task can have a Task: control file field that lists the names of tasks they are a part of. This field can also be added to the Packages file by way of an override, even if a package does not contain it. Doing things this way has a lot of benefits that AJ has recently enumerated. It also probably has some long term drawbacks: it doesn't generalise all that immediately to allowing upgrading tasks, nor removing tasks. But then, it might. In any case though, these things aren't going to be implemented in time for woody, so it's more important now to get something that *works* (allows us to have tasks for installation, and doesn't break when we get into the freeze properly). + p + You should not tag any packages as belonging to a task before + this has been discussed on the `debian-devel' mailing list and + a consensus about doing that has been reached. + /p Actually, I'm assuming the overrides mechanism will just ignore any Task: fields that might be in a package... Cheers, a consensus by any means necessary j -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net) pgpT9d9diVMrq.pgp Description: PGP signature
Bug#97755: PROPOSAL] eliminating task packages; new task system
On Wed, 16 May 2001, Joey Hess wrote: --- policy.sgml.orig Tue May 15 21:57:25 2001 +++ policy.sgml Tue May 15 22:14:28 2001 @@ -1024,6 +1024,38 @@ /p /sect1 +sect1 + headingTasks/heading + + p + The Debian install process allows the user to choose from + a number of common tasks which a Debian system can be used to + perform. Selecting a task with prgntasksel/prgn causes + a set of packages that are useful in performing that task to be + installed. + /p + + p + This set of packages is all available packages which have the + name of the selected task in the ttTasktt field of their + control file. The format of this field is a list of tasks, + separated by commas. + /p + + p + You should not tag any packages as belonging to a task before + this has been discussed on the `debian-devel' mailing list and + a consensus about doing that has been reached. + /p + + p + For third parties (and historical reasons), tasksel also + supports constructing tasks based on `task packages'. These are + packages whose names begin with `task-'. Task packages should + not be included in the Debian archive. + /p + /sect1 + sect1 headingMaintainer scripts/heading @@ -1282,8 +1309,8 @@ p Having a separate package allows one to install the build-essential packages on a machine, as - well as allowing other packages such as task - packages to require installation of the + well as allowing other packages and tasks + to require installation of the build-essential packages using the depends relation. /p Seconded. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh pgp4xSS9S1WBw.pgp Description: PGP signature
Bug#97755: PROPOSAL] eliminating task packages; new task system
[Sorry if I'm talking nonsense here; I've only recently started reading debian-policy again, so I may be further out of touch than I think.] On Thu, May 17, 2001 at 05:46:48PM +1000, Anthony Towns wrote: Rather than having task packages any more, individual packages that belong to a task can have a Task: control file field that lists the names of tasks they are a part of. This field can also be added to the Packages file by way of an override, even if a package does not contain it. Doing things this way has a lot of benefits that AJ has recently enumerated. It also probably has some long term drawbacks: it doesn't generalise all that immediately to allowing upgrading tasks, nor removing tasks. Since the task wouldn't actually be installed in any permanent sense (there's no task package to install), upgrading a task would probably just consist of selecting it again with tasksel. tasksel would scan the available file and mark for installation anything which has the appropriate value in its Task: line. It's not really possible to remove a task at present. You can remove its task package... or you could hunt down all the task package's dependencies and remove them. Under the proposed setup, tasksel could mark all the packages making up the task for removal. -- Charles Briscoe-Smith Hacking Free Software for Alcove PGP/GPG: 1024R/B35EE811 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 I sign these contracts / that means I'm willing / to keep on doing bloody awful evil things / [...] No! No! / This nightmare must come to an end! -- Seymour, Little Shop of Horrors, lyrics by Howard Ashman, apparently referring to the ethics of signing non-disclosure agreements
Re: Bug#97755: [PROPOSAL] eliminating task packages; new task system
Hi, Should we not wait until we have a working system before we write this down in stone? It seems likely that we shall have design tweaks as we work through implementing this, and once the design and the interfaces have stabilized would be the time to propose this as policy. This is in line with the notion that policy documents current practice. Mind you, I like the proposal, and were it not for the issue of timing, I would probably have seconded this. manoj -- It is an important and popular fact that things are not always what they seem. For instance, on the planet Earth, man had always assumed that he was more intelligent than dolphins because he had achieved so much -- the wheel, New York, wars and so on -- whilst all the dolphins had ever done was muck about in the water having a good time. But conversely, the dolphins had always believed that they were far more intelligent than man -- for precisely the same reasons. Curiously enough, the dolphins had long known of the impending destruction of the of the planet Earth and had made many attempts to alert mankind to the danger; but most of their communications were misinterpreted ... Douglas Admas The Hitchhikers' Guide To The Galaxy Manoj Srivastava [EMAIL PROTECTED] 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
Bug#97755: PROPOSAL] eliminating task packages; new task system
On Thu, May 17, 2001 at 11:18:17PM +0100, Charles Briscoe-Smith wrote: Since the task wouldn't actually be installed in any permanent sense (there's no task package to install), upgrading a task would probably just consist of selecting it again with tasksel. Well, it depends how/if you want to handle the possibility of, say, the web-server task using apache in woody, and say, boa in woody+1. Should upgrading the task move you over to boa? Should it give you the opportunity to do so? Likewise if packages get added, or removed? It's not really possible to remove a task at present. You can remove its task package... or you could hunt down all the task package's dependencies and remove them. And all their dependencies, and so on. Unless something else you've got installed depends on them too. Someone (and it won't be me :) will probably want to think about these things after woody. But it doesn't much matter at the moment. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``_Any_ increase in interface difficulty, in exchange for a benefit you do not understand, cannot perceive, or don't care about, is too much.'' -- John S. Novak, III (The Humblest Man on the Net)
Re: Bug#97755: PROPOSAL] eliminating task packages; new task system
Manoj Srivastava wrote: Should we not wait until we have a working system before we write this down in stone? It seems likely that we shall have design tweaks as we work through implementing this, and once the design and the interfaces have stabilized would be the time to propose this as policy. This is in line with the notion that policy documents current practice. I implemented it today. Didn't have to change any of the design; AJ and I hammered it through pretty well prior. Tasksel 1.3 is checked into cvs and ready for upload, though I won't for a few days. Well, I implemented the part of it that affects tasksel. There is a part that is not part of the formal proposal and really has nothing to do with policy that has to do with editing overrides files. AJ is going to work on that. Then there is another part that has to do with actually defining the new tasks and what packages go in them; the working group is going to take care of that, and we'll begin if we can find a third member. Mind you, I like the proposal, and were it not for the issue of timing, I would probably have seconded this. It's all about timing, unfortunatly -- we have to get this done before woody base is frozen, and that includes getting the old task packages removed. I think we will though, and will probably have it almostly completly implemented by the time the discussion period is up and it goes into policy. -- see shy jo
Bug#97755: [PROPOSAL] eliminating task packages; new task system
Package: debian-policy Severity: wishlist Introduction: After a lot of discussion, AJ and I have settled on a compromise that is acceptable to both of us about what to do to fix Debian's broken[1] task system. Essentially, we propose throwing out all existing task packages, no longer using packages at all to deliver task information, formalizing the process by which tasks are modified/added, and moving the information about what packages belong in each task out to the packages themselves (or to the Packages file). The new system: Rather than having task packages any more, individual packages that belong to a task can have a Task: control file field that lists the names of tasks they are a part of. This field can also be added to the Packages file by way of an override, even if a package does not contain it. Doing things this way has a lot of benefits that AJ has recently enumerated. That is half of the data tasksel needs to display a task. The other half is a description of the task (and ancillay information like the name of the task, a section it is in, etc). That information will be delivered to tasksel in the form of a single file (format much like a debian/control file) which will ship with tasksel or in another package. We have decided not to use individual debian packages for reasons which I have recently discussed[2]. Tasksel will be modified[3] to put these two sources of information together and display tasks for selection much as it does now. Woody: To roll this out in time for woody's freeze, we will make heavy use of the overrides to add Task: fields to the Packages files. The possibility is left open that later the overrides might be done away with, or packages will at least be able to include matching Task: fields, but we're not going to do that for woody, since there isn't time. To make this happen in time for woody, I want to form a task force of 3 to 5 people to, in the next 3 weeks, look at the existing task packages, and decide on a list of tasks that should come with woody, and come up with the lists of packages that go in the tasks. This is intended as a bootstrapping effort, not a group that will have long term control over the tasks. If you're interested in being on the task force, please mail me. Proposal: Here's the actual proposal. I am of course looking for seconds. --- policy.sgml.origTue May 15 21:57:25 2001 +++ policy.sgml Tue May 15 22:14:28 2001 @@ -1024,6 +1024,38 @@ /p /sect1 +sect1 + headingTasks/heading + + p + The Debian install process allows the user to choose from + a number of common tasks which a Debian system can be used to + perform. Selecting a task with prgntasksel/prgn causes + a set of packages that are useful in performing that task to be + installed. + /p + + p + This set of packages is all available packages which have the + name of the selected task in the ttTasktt field of their + control file. The format of this field is a list of tasks, + separated by commas. + /p + + p + You should not tag any packages as belonging to a task before + this has been discussed on the `debian-devel' mailing list and + a consensus about doing that has been reached. + /p + + p + For third parties (and historical reasons), tasksel also + supports constructing tasks based on `task packages'. These are + packages whose names begin with `task-'. Task packages should + not be included in the Debian archive. + /p + /sect1 + sect1 headingMaintainer scripts/heading @@ -1282,8 +1309,8 @@ p Having a separate package allows one to install the build-essential packages on a machine, as - well as allowing other packages such as task - packages to require installation of the + well as allowing other packages and tasks + to require installation of the build-essential packages using the depends relation. /p (AJ, note that I have changed it a bit from what you saw.) -- see shy jo [1] For the many reasons why we consider it broken and why it cannot be fixed in its current form, see discussions on debian-boot, debian-policy, and debian-devel in the past half year or so. Or just run tasksel sometime. [2] Perhaps most lucidly at the end of [EMAIL PROTECTED] [3] I'm starting work on that soon.
