public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ryan Hill <dirtyepic@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev]  Re: Proposal for how to handle stable ebuilds
Date: Mon, 17 Nov 2008 19:08:06 -0600	[thread overview]
Message-ID: <20081117190806.3ffe2dbb@halo.dirtyepic.sk.ca> (raw)
In-Reply-To: 1226934657.4891.21.camel@athena.ghs.com

[-- Attachment #1: Type: text/plain, Size: 3281 bytes --]

On Mon, 17 Nov 2008 10:10:57 -0500
Daniel Gryniewicz <dang@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  reply	other threads:[~2008-11-18  1:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-10 18:13 [gentoo-dev] Proposal for how to handle stable ebuilds Mark Loeser
2008-11-10 18:23 ` Ciaran McCreesh
2008-11-10 18:23 ` Mart Raudsepp
2008-11-10 20:32   ` Steev Klimaszewski
2008-11-10 21:16 ` Jeremy Olexa
2008-11-10 21:57 ` Santiago M. Mola
2008-11-11  0:24 ` Jose Luis Rivero
2008-11-11  1:13   ` Mark Loeser
2008-11-11  9:31     ` Jose Luis Rivero
2008-11-11  1:21   ` Richard Freeman
2008-11-11  8:56     ` Peter Volkov
2008-11-11 10:18     ` Jose Luis Rivero
2008-11-11 13:49       ` Ferris McCormick
2008-11-11 16:06       ` [gentoo-dev] " Duncan
2008-11-11 16:24         ` Jeroen Roovers
2008-11-11 17:26           ` Duncan
2008-11-11 17:55             ` Ferris McCormick
2008-11-11 18:12             ` Jeroen Roovers
2008-11-11 21:03               ` Duncan
2008-11-13 17:38 ` [gentoo-dev] " Tobias Scherbaum
2008-11-15 13:02   ` Matti Bickel
2008-11-17 18:08     ` Tobias Scherbaum
2008-11-17 19:03       ` [gentoo-dev] " Duncan
2008-12-11  5:35       ` [gentoo-dev] " Donnie Berkholz
2008-11-17  0:38 ` [gentoo-dev] " Ryan Hill
2008-11-17 15:10   ` Daniel Gryniewicz
2008-11-18  1:08     ` Ryan Hill [this message]
2008-11-18 16:57       ` Daniel Gryniewicz
2008-11-18 17:50         ` Ciaran McCreesh
2008-11-18 20:31           ` Daniel Gryniewicz
2008-11-18 21:18         ` Ryan Hill
2008-11-18 22:04           ` Daniel Gryniewicz
2008-11-18 22:45             ` Ryan Hill
2008-11-30 22:59 ` Ryan Hill
2008-12-01  7:49   ` Peter Volkov
2008-12-11  5:37 ` [gentoo-dev] " Donnie Berkholz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081117190806.3ffe2dbb@halo.dirtyepic.sk.ca \
    --to=dirtyepic@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox