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