public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Chris Gianelloni <wolf31o2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Some ideas on how to reduce territoriality
Date: Fri, 03 Aug 2007 15:47:27 -0700	[thread overview]
Message-ID: <1186181247.8470.52.camel@inertia.twi-31o2.org> (raw)
In-Reply-To: <46B3A9D4.9090502@gentoo.org>

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

On Fri, 2007-08-03 at 15:19 -0700, Mike Doty wrote:
> Chris Gianelloni wrote:
> [snip]
> 
> > 
> > There's a couple more that I wouldn't mind seeing as things developers
> > can do without the maintainer, but I can see how these might be a bit
> > more controversial, so I'm asking for input.
> > 
> > - Version bumps where the only requirement is to "cp" the ebuild
> This is more on a per package basis.  it's not fair to force the maintainer to
> support a new version before he feels it's ready.  For example, I'd love to
> bump games-simulation/simutrans but Mr_Bones_ claims it's unstable and doesn't
> want it bumped.  It wouldn't be fair to him for me to bump it unless I took the
> burden of support.

This is why I said it should be discussed.  Also, it might very likely
be better to opt-out rather than opt-in on this.  I really don't know,
myself.

> > - (for arch teams) Stabilization of new revisions of an already stable
> > package - An example of this would be being able to stabilize foo-1.0-r2
> > if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is
> > stable.
> arch teams are the definitive authority on keywording for their arch.  That
> said, if there is a disagreement between maintainer and arch team, the support
> burden falls on whoever did the keyword.  Teamwork should solve this problem
> every time.

Well, I meant that this should be doable without the maintainer's
consent.  Meaning, I ask you to stabilize 1.0-r1 and a few weeks later,
you can decide to stabilize -r2 without me having to file a bug.
Basically, the maintainer decides the minimal revision he wants to go
stable (so bugs are fixed, etc) but the revisions after that are up to
the arch teams, unless the maintainer sees a need for everyone to update
(major bug, security).  My main goal here is to reduce the "we have to
wait on the maintainer to ask" issue within a given version of a
package.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2007-08-03 22:51 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-03 22:06 [gentoo-dev] Some ideas on how to reduce territoriality Chris Gianelloni
2007-08-03 22:19 ` Mike Doty
2007-08-03 22:47   ` Chris Gianelloni [this message]
2007-08-04  7:21     ` Marius Mauch
2007-08-03 22:23 ` Philipp Riegger
2007-08-03 22:34   ` Petteri Räty
2007-08-03 22:40     ` Donnie Berkholz
2007-08-03 23:03       ` Mike Doty
2007-08-03 23:06         ` Mike Doty
2007-08-03 23:20           ` Robin H. Johnson
2007-08-04 14:43             ` [gentoo-dev] Commitlog-mailinglist (was: Re: Some ideas on how to reduce territoriality) Lars Weiler
2007-08-04 19:32               ` [gentoo-dev] Commitlog-mailinglist Donnie Berkholz
2007-08-06  9:41                 ` [gentoo-dev] Commitlog-mailinglist Christian Faulhammer
2007-08-06 12:23               ` [gentoo-dev] Commitlog-mailinglist (was: Re: Some ideas on how to reduce territoriality) Mike Frysinger
2007-08-06 14:43                 ` [gentoo-dev] Commitlog-mailinglist Lars Weiler
2007-08-06 15:01                   ` Ned Ludd
2007-08-06 15:48                     ` Lars Weiler
2007-08-06 16:20                       ` Petteri Räty
2007-08-03 22:43     ` [gentoo-dev] Some ideas on how to reduce territoriality Philipp Riegger
2007-08-03 22:23 ` Petteri Räty
2007-08-03 22:49   ` Chris Gianelloni
2007-08-04  7:36     ` Marius Mauch
2007-08-03 22:53 ` Roy Marples
2007-08-04  1:13 ` Luis Francisco Araujo
2007-08-06 19:16   ` Chris Gianelloni
2007-08-07  3:48     ` [gentoo-dev] " Steve Long
2007-08-04  9:06 ` [gentoo-dev] " Alec Warner
2007-08-04 16:29   ` [gentoo-dev] " Steve Long
2007-08-04 17:17     ` Martin Jackson
2007-08-04 17:27 ` [gentoo-dev] " Jeroen Roovers
2007-08-04 17:39   ` Vlastimil Babka
2007-08-04 17:56     ` Steev Klimaszewski
2007-08-04 20:05       ` Petteri Räty
2007-08-04 23:56         ` Jurek Bartuszek
2007-08-05  6:27           ` Jeroen Roovers
2007-08-06 12:26         ` Mike Frysinger
2007-08-06 16:18           ` Petteri Räty
2007-08-07  0:23             ` Mike Frysinger
2007-08-05  0:03     ` [gentoo-dev] " Steve Long
2007-08-05  7:50       ` Petteri Räty
2007-08-04 19:34 ` Tiziano Müller
2007-08-05  0:19   ` Steve Long
2007-08-05 16:14 ` [gentoo-dev] " Ciaran McCreesh
2007-08-06 14:09   ` [gentoo-dev] " Steve Long
2007-08-06  9:24 ` Christian Faulhammer
2007-08-06 11:16 ` [gentoo-dev] " Paul de Vrieze

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=1186181247.8470.52.camel@inertia.twi-31o2.org \
    --to=wolf31o2@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