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
