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.

> 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