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
signature.asc
Description: This is a digitally signed message part
