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
