On Mon, 2008-11-17 at 19:08 -0600, Ryan Hill wrote:
> On Mon, 17 Nov 2008 10:10:57 -0500
> Daniel Gryniewicz <dang@g.o> 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