1 |
On Fri, 2007-08-03 at 15:19 -0700, Mike Doty wrote: |
2 |
> Chris Gianelloni wrote: |
3 |
> [snip] |
4 |
> |
5 |
> > |
6 |
> > There's a couple more that I wouldn't mind seeing as things developers |
7 |
> > can do without the maintainer, but I can see how these might be a bit |
8 |
> > more controversial, so I'm asking for input. |
9 |
> > |
10 |
> > - Version bumps where the only requirement is to "cp" the ebuild |
11 |
> This is more on a per package basis. it's not fair to force the maintainer to |
12 |
> support a new version before he feels it's ready. For example, I'd love to |
13 |
> bump games-simulation/simutrans but Mr_Bones_ claims it's unstable and doesn't |
14 |
> want it bumped. It wouldn't be fair to him for me to bump it unless I took the |
15 |
> burden of support. |
16 |
|
17 |
This is why I said it should be discussed. Also, it might very likely |
18 |
be better to opt-out rather than opt-in on this. I really don't know, |
19 |
myself. |
20 |
|
21 |
> > - (for arch teams) Stabilization of new revisions of an already stable |
22 |
> > package - An example of this would be being able to stabilize foo-1.0-r2 |
23 |
> > if foo-1.0 (or foo-1.0-r1) is already stable, but not if only foo-0.9 is |
24 |
> > stable. |
25 |
> arch teams are the definitive authority on keywording for their arch. That |
26 |
> said, if there is a disagreement between maintainer and arch team, the support |
27 |
> burden falls on whoever did the keyword. Teamwork should solve this problem |
28 |
> every time. |
29 |
|
30 |
Well, I meant that this should be doable without the maintainer's |
31 |
consent. Meaning, I ask you to stabilize 1.0-r1 and a few weeks later, |
32 |
you can decide to stabilize -r2 without me having to file a bug. |
33 |
Basically, the maintainer decides the minimal revision he wants to go |
34 |
stable (so bugs are fixed, etc) but the revisions after that are up to |
35 |
the arch teams, unless the maintainer sees a need for everyone to update |
36 |
(major bug, security). My main goal here is to reduce the "we have to |
37 |
wait on the maintainer to ask" issue within a given version of a |
38 |
package. |
39 |
|
40 |
-- |
41 |
Chris Gianelloni |
42 |
Release Engineering Strategic Lead |
43 |
Alpha/AMD64/x86 Architecture Teams |
44 |
Games Developer/Council Member/Foundation Trustee |
45 |
Gentoo Foundation |