[gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Mon, 10 Nov 2008 13:13:34 -0500 Mark Loeser [EMAIL PROTECTED] wrote: Instead of addressing archs as being slackers or not, this addresses it as a more granular layer of looking at ebuilds. Thanks to Richard Freeman for the initial proposal that I based this off of. Please give me feedback on this proposal, if you think it sucks (preferably with an explanation why), or if you think it might work. Ebuild Stabilization Time Arch teams will normally have 30 days from the day a bug was filed, keyworded STABLEREQ, the arch was CCed, and the maintainer either filed the bug or commented that it was OK to stabilize (clock starts when all of these conditions are met). Security bugs are to be handled by the policies the Security Team has established. Technical Problems with Ebuild Revisions If an arch team finds a technical problem with an ebuild preventing stabilization, a bug will be logged as a blocker for the keyword request. The bug being resolved resets the time for the 30 days the arch team has to mark the ebuild stable. Removing Stable Ebuilds If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY choose to delete an older version even if it is the most recent stable version for a particular arch. If an ebuild meets the time criteria above, but there is a technical issue preventing stabilization, and there are no outstanding security issues, then the maintainer MUST not remove the highest-versioned stable ebuild for any given arch without the approval of the arch team. Security issues are to be handled by the recommendations of the Security Team. Spirit of Cooperation Ebuild maintainer and arch teams are encouraged to work together for the sake of each other and end users in facilitating the testing and maintenance of ebuilds on obscure hardware, or where obscure expertise is needed. Package maintainers are encouraged to use discretion when removing ebuilds in accordance with this policy. Since I completely stalled out this conversation I guess it's only fair that I try to restart it. I'm in favor of the above. I know it's not directly related to stabilization, but lately people have been removing the only keyworded package for the mips arch, under the excuse that's it's been over 30 days since they opened a keywording bug. This has been happening on bugs where there are technical issues and on bugs where we just haven't replied (in which case i can see the justification). I don't think this is acceptable, just as I don't think removing the only stable version of a package on an arch is be acceptable, barring the circumstances Mark outlined above. Yes? No? Get out of our treehouse? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
В Вск, 30/11/2008 в 16:59 -0600, Ryan Hill пишет: On Mon, 10 Nov 2008 13:13:34 -0500 Mark Loeser [EMAIL PROTECTED] wrote: [proposal] I know it's not directly related to stabilization, but lately people have been removing the only keyworded package for the mips arch, under the excuse that's it's been over 30 days since they opened a keywording bug. This has been happening on bugs where there are technical issues and on bugs where we just haven't replied (in which case i can see the justification). I don't think this is acceptable, just as I don't think removing the only stable version of a package on an arch is be acceptable, barring the circumstances Mark outlined above. That people should revert back that ebuilds then. Of course it's not acceptable to remove keywords just because of one's wishes. As it was told in this thread old ebuilds are not maintainer's concern and he/she could touch them only after all arch teams finish their work. Until they done all bugs in old ebuilds should be assigned on arch teams. -- Peter.
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote: On Mon, 17 Nov 2008 10:10:57 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: snip The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the latest stable ebuild of an arch without the approval of the arch team or he/she will be fed to the Galrog. As long as the maintainer can pass off the maintenance of the (sometimes dozens) of ancient ebuilds that need to be kept around for that one arch to the arch team, and re-assign any resulting bugs to them, fine. Since when do we maintain ancient ebuilds kept around for an arch team now? Drop the other keywords and get on with your life. Since forever, at least in my experience. See below. Did you not read the first part of the suggestion? Yes. I was not objecting to this sequence. I was objecting to the MUST NOT NEVER EVER NOT EVEN A LITTLE BIT part. - maintainer files a stabilization request. - arch testers do their thing - arch teams gradually mark ebuild stable - maintainer pokes arm, sh, mips, ppc (only an example, relax) - mips reminds maintainer there is no stable mips keyword - ppc stables - maintainer waits - maintainer pokes arm, sh - maintainer waits - maintainer marks stable on arm, sh - maintainer removes ancient stable ebuilds that maintainer doesn't want to maintain anymore because everyone has a nice new stable ebuild. - maintainer goes out for a frosty beverage - Arch team comes back and says the new version doesn't work. - Maintainer is stuck maintaining the old version *forever*, at least potentially. Concrete example. Gnome was keyworded on an arch. A new version of gnome came out that needed hal. Hal did not work on said arch. For a long long time, we had to keep a very old version of gnome in the tree, just for that arch. This was a maintenance burden. Gnome is not just one or 2 packages. the idea is that arch teams are around to help the maintainer test on architectures the maintainer doesn't have. if the arch teams are unable or unwilling to help at the moment, that should not stop the maintainer from maintaining. also keep in mind that this only occurs after the arch teams have ample time to interject (which is why i suggested 90 days). if an arch team can't comment on a bug in 3 months (a simple i'd rather this not go stable until i can test it further should be enough) then they have IMO lost their opportunity to matter. This is not about arches just being slackers. This is about arches denying stable (or even ~) for some reason. If I cannot drop an old version of something just because the new version doesn't (and won't) work on an arch, that's really bad for me. Daniel
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 18 Nov 2008 11:57:23 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: This is not about arches just being slackers. This is about arches denying stable (or even ~) for some reason. If I cannot drop an old version of something just because the new version doesn't (and won't) work on an arch, that's really bad for me. What is the cost of keeping it there and not changing it? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 2008-11-18 at 17:50 +, Ciaran McCreesh wrote: On Tue, 18 Nov 2008 11:57:23 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: This is not about arches just being slackers. This is about arches denying stable (or even ~) for some reason. If I cannot drop an old version of something just because the new version doesn't (and won't) work on an arch, that's really bad for me. What is the cost of keeping it there and not changing it? Assuming no one ever uses it? Just some sync bandwidth, emerge think time, and disk space. Not a lot. However, if people use it, and especially if they manage to get mixed versions of gnome with it (or new versions of apps built against it), then we get lots of bugs about it. Generally, we tend to get lots of interaction bugs about old versions of gnome. That's why we try to remove them. One of the biggest problems is packages not having the correct upstream deps, since upstream and most distros have moved on to new versions of gnome. There's no way we can catch those (since we, too, have moved on to new versions) and users find them and report them. Most users I've encountered don't do --deep upgrades, ever. I suppose a possible solution would be to de-keyword all those old versions for all other arches. That would reduce such reported bugs to users of the arch in question. It still leaves something unmaintained (and probably unmaintainable, except maybe on the target arch) in the tree marked as stable. That's a bad thing in-and-of itself. Daniel
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 2008-11-18 at 15:18 -0600, Ryan Hill wrote: On Tue, 18 Nov 2008 11:57:23 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote: On Mon, 17 Nov 2008 10:10:57 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: snip The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the latest stable ebuild of an arch without the approval of the arch team or he/she will be fed to the Galrog. As long as the maintainer can pass off the maintenance of the (sometimes dozens) of ancient ebuilds that need to be kept around for that one arch to the arch team, and re-assign any resulting bugs to them, fine. Since when do we maintain ancient ebuilds kept around for an arch team now? Drop the other keywords and get on with your life. Since forever, at least in my experience. See below. Did you not read the first part of the suggestion? Yes. I was not objecting to this sequence. I was objecting to the MUST NOT NEVER EVER NOT EVEN A LITTLE BIT part. - maintainer files a stabilization request. - arch testers do their thing - arch teams gradually mark ebuild stable - maintainer pokes arm, sh, mips, ppc (only an example, relax) - mips reminds maintainer there is no stable mips keyword - ppc stables - maintainer waits - maintainer pokes arm, sh - maintainer waits - maintainer marks stable on arm, sh - maintainer removes ancient stable ebuilds that maintainer doesn't want to maintain anymore because everyone has a nice new stable ebuild. - maintainer goes out for a frosty beverage - Arch team comes back and says the new version doesn't work. - Maintainer is stuck maintaining the old version *forever*, at least potentially. See, here's your problem. If the arch team has issues and needs an old ebuild, the arch team is effectively the maintainer of that ebuild. Drop the other keywords if you like, and forget it exists. Leaving unmaintained ebuilds in the tree. If that's what people want, that's fine with me. Concrete example. Gnome was keyworded on an arch. A new version of gnome came out that needed hal. Hal did not work on said arch. For a long long time, we had to keep a very old version of gnome in the tree, just for that arch. This was a maintenance burden. Gnome is not just one or 2 packages. So you would rather have the ability to just drop the keywords on this arch and leave them and their gnome users up the creek? No. But I also don't want any policy that forbids me from ever removing that ebuild. Which is what the above is proposing. I don't want any kind of absolutes in policy. If you advocate absolutes in favor of the arch teams to the detriment of the maintainers, then the maintainers are going to ask for absolutes (such as I asked for above) in retaliation, and we'll have a thermonuclear meltdown. That's all. Honestly, I don't want to be a dick to the arch teams. I really don't. But I *also* don't want them (or policy) to be a dick to me. That's my whole point; that requirement of never removing the last stable ebuild, in shouting caps no less, is way too absolute, and is just going to piss people like me off. I think the whole policy should be more-or-less Don't be a dick. Take the other guy into account. Leave shouting-caps absolute requirements out of it. (For what it's worth, with my arch team hat on, I'm not in favor of letting anyone mark things stable on arches they can't test on. But that's a much lesser issue IMO than absolute prohibitions on removing ebuilds.) Daniel
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 18 Nov 2008 17:04:33 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: Honestly, I don't want to be a dick to the arch teams. I really don't. But I *also* don't want them (or policy) to be a dick to me. That's my whole point; that requirement of never removing the last stable ebuild, in shouting caps no less, is way too absolute, and is just going to piss people like me off. For the record, the all in caps bit was a tongue-in-cheek reference to the ultra-formal format that the IETF RFC's are in that was being emulated here. It was included for levity, not for shouting. http://www.rfc-editor.org/rfc/rfc2119.txt -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
Tobias Scherbaum [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 17 Nov 2008 19:08:39 +0100: Process might be as easy as CC'ing a arch-tinderbox on a bug, a script does parse the bug number out of the mail being sent out and using gatt it catches the ebuild to test, compiles it and reports back a) failure/success, b) error log as attachment if it fails plus c) if there was a test-phase. Surely, you're talking something other than the publicly writable CC field, something writable by devs (and maybe ATs) only, right? Otherwise it's a security nightmare. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Mon, 17 Nov 2008 10:10:57 -0500 Daniel Gryniewicz [EMAIL PROTECTED] wrote: On Sun, 2008-11-16 at 18:38 -0600, Ryan Hill wrote: snip The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the latest stable ebuild of an arch without the approval of the arch team or he/she will be fed to the Galrog. As long as the maintainer can pass off the maintenance of the (sometimes dozens) of ancient ebuilds that need to be kept around for that one arch to the arch team, and re-assign any resulting bugs to them, fine. Since when do we maintain ancient ebuilds kept around for an arch team now? Drop the other keywords and get on with your life. Or, alternatively, unilaterally decide to drop all keywords for the arch in question. Yes, that was extreme, but no more than the previous quoted statement. You sir, have an appointment with the Galrog. There needs to be give and take here. Yes, it's really bad to remove the last stable ebuild for an arch. However, its *also* bad to have to maintain years old versions of lots of ebuilds. And yes, it will be a lot, since most packages don't exist in a vacuum, and require older deps (which possibly will be maintained by other maintainers than the first package, causing a cascade of old packages in the tree). All this will do in practice is cause maintainers to ignore bugs for those old packages for those few arches, since the maintainer won't have that version installed. In fact, in my experience, they frequently *can't* have that version installed, since it requires older versions of other packages that need to be upgraded to maintain newer versions of the same package. How much bit rot do we want in the tree? Daniel (who is both an arch team member and gnome team lead) Did you not read the first part of the suggestion? - maintainer files a stabilization request. - arch testers do their thing - arch teams gradually mark ebuild stable - maintainer pokes arm, sh, mips, ppc (only an example, relax) - mips reminds maintainer there is no stable mips keyword - ppc stables - maintainer waits - maintainer pokes arm, sh - maintainer waits - maintainer marks stable on arm, sh - maintainer removes ancient stable ebuilds that maintainer doesn't want to maintain anymore because everyone has a nice new stable ebuild. - maintainer goes out for a frosty beverage the idea is that arch teams are around to help the maintainer test on architectures the maintainer doesn't have. if the arch teams are unable or unwilling to help at the moment, that should not stop the maintainer from maintaining. also keep in mind that this only occurs after the arch teams have ample time to interject (which is why i suggested 90 days). if an arch team can't comment on a bug in 3 months (a simple i'd rather this not go stable until i can test it further should be enough) then they have IMO lost their opportunity to matter. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Mon, 10 Nov 2008 13:13:34 -0500 Mark Loeser [EMAIL PROTECTED] wrote: If an ebuild meets the time criteria above, and there are no technical issues preventing stabilization, then the maintainer MAY [...] mark that ebuild as stable on every keyworded arch (that has a stable keyword). If an ebuild meets the time criteria above, but there is a technical issue preventing stabilization, and there are no outstanding security issues, [...] the maintainer MUST NOT mark the ebuild stable without the approval of the arch team. If technical issues arise after an ebuild is stabilized automatically, the arch team MAY revert the ebuild to ~arch if another ebuild with a stable keyword is still available or restore the previous stable ebuild to the tree if not, until such time that the issue is resolved, or stabilize a later versioned ebuild that does not exhibit the issue at the maintainer's approval. The maintainer MUST NOT NEVER EVER NOT EVEN A LITTLE BIT remove the latest stable ebuild of an arch without the approval of the arch team or he/she will be fed to the Galrog. and s/30 days/90 days/g. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 2008-11-11 at 17:26 +, Duncan wrote: Jeroen Roovers [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Nov 2008 17:24:50 +0100: Words like production, critical and important can be applied as easily to the state of a company's or nation's system as to a single person's. Yes, but it's a relative thing. They obviously do what they can with the resources they have (are willing to dedicate). We do the same. A user's single system will absolutely be important to him, no doubt about it, but if he doesn't believe it worth superhuman feats or prioritizing to ensure it's safety, neither should we. I think I understand what you mean here, but it's not what you wrote as best as I can tell. As a developer, I believe it is my responsibility to work a bit harder just so that the users don't have to resort to 'superhuman feats' to keep their systems running. I do agree that no matter what we provide, all users (including ourselves) will have to expend some effort to take advantage of it. No, we don't go around purposefully breaking things, but both he and we have limits to our resources and certain priorities in their allocation, and if he's not placing undue priority on the safety of his machine, why is it even a question if we will? The presumption should be actions within the bounds of rational reality and prioritization of resources for both users and their distribution, us. No more, no less. IOW, I'd have agreed if the point was that it's a machine that's useful to the user and that he doesn't want broken, and we should behave accordingly, but the triple emphasis of important, production, critical, seemed a bit undue for the lengths to which an ordinary user goes or the priority he reveals by his own actions. And if his actions reveal a SERIOUS priority in the area, than he's already covered by definition. That's all I was saying. Regards, Ferris -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Proposal for how to handle stable ebuilds
On Tue, 11 Nov 2008 16:06:02 + (UTC) Duncan [EMAIL PROTECTED] wrote: If it's a production, critical, important system, then what is one doing installing updates on it directly without verifying them on a generally identical test system first? Now you're ridiculing the idea of having a production/ critical/ important system. Most of our users probably use a single Gentoo machine (I see many cases where users have multiple machines, but only one running Gentoo, or have one machine running several operating systems), and for them an important system is one that they cannot readily replace. Words like production, critical and important can be applied as easily to the state of a company's or nation's system as to a single person's. The stable branch has never been about commercial systems and their stringent requirements[1] - it's all about this level of quality that has users up in arms about one package blocking another or one package requiring half the system to be rebuilt at a rate of no more than once a year[2]. Kind regards, jer [1] We've had calls for an über-stable project in the past that would lock down versions and backport patches for enterprise systems. [2] I.e. when we break the promise of [3]. ]3] http://www.gentoo.org/main/en/philosophy.xml
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
Jeroen Roovers [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Nov 2008 19:12:41 +0100: You did it again in the IOW quotation above explaining it as a triple emphasis instead of what it was intended to denote, namely as a few possible examples of the meaning of stability. In that case, I misread, as I interpreted the triple as emphasis, not alternatives. If it was intended as alternatives, then yes, it makes sense. Thanks. I wasn't seeing the alternatives view at all (obviously). -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Proposal for how to handle stable ebuilds
Jose Luis Rivero [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 11 Nov 2008 11:18:34 +0100: Mixing software branches is very easy in the Gentoo world but it has some problems. Are you going to install in your stable (production, critial, important,...) system a combination of packages not tested before? Your general post I agree with, but this part... If it's a production, critical, important system, then what is one doing installing updates on it directly without verifying them on a generally identical test system first? Either it's not actually so important in the grand scheme of things after all, or one will certainly find out eventually just how critical said machine is when it goes down due to live testing on a production critical machine. Of course, that doesn't excuse a distribution doing its best to ensure that doesn't happen, but no distribution is perfect. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
