1 |
On Friday 16 September 2005 05:57 pm, Martin Schlemmer wrote: |
2 |
> On Fri, 2005-09-16 at 16:59 -0400, Mike Frysinger wrote: |
3 |
> > On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote: |
4 |
> > > On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <vapier@g.o> |
5 |
> > > |
6 |
> > > wrote: |
7 |
> > > | ok, e17 packages dont count here. however, your hardcore view i |
8 |
> > > | still dont buy. how about the baselayout-1.9.x -> baselayout-1.11.x |
9 |
> > > | stabilization process ? are you telling me that arch teams should |
10 |
> > > | have had the power to move those into stable without talking to the |
11 |
> > > | maintainer ? baselayout may be a core package, but if you continue |
12 |
> > > | with your hard rule here, then it doesnt matter. |
13 |
> > > |
14 |
> > > I'm saying that arch teams should be allowed to mark it stable if they |
15 |
> > > think it's appropriate. Not that it must be moved to stable after $x |
16 |
> > > days, but that it can be at the arch team's discretion. And any arch |
17 |
> > > team which is silly enough to mark a broken baselayout stable has far |
18 |
> > > bigger problems anyway... |
19 |
> > |
20 |
> > baselayout is an example, any package can be used here (although not many |
21 |
> > are as critical) |
22 |
> > |
23 |
> > i'm saying that the maintainer may have a certain idea of when the |
24 |
> > package is ready for stable (a target feature set, working out certain |
25 |
> > quirks, etc...). your current hard view does not allow for that. for |
26 |
> > example, i had an arch maintainer one time mark bash-3 stable before |
27 |
> > base-system was ready for it (readline, baselayout, etc... were going to |
28 |
> > be stabilized together). i smacked them hard for it, but if we went with |
29 |
> > this hard view, it would have been perfectly acceptable behavior. |
30 |
> |
31 |
> We still have KEYWORDS="-*". Sure, I know many do not like it, and if |
32 |
> something was decided in regards to it, I missed it, but it is generally |
33 |
> seen as 'less severe' than a package.mask'd mask, and its local to the |
34 |
> package, so should not get stale. |
35 |
|
36 |
that would address the 'arch teams marking ahead of maintainer' issue, but in |
37 |
general, i think we need a testing mask of some sort separate from |
38 |
package.mask where we can put things like modular X, new KDE betas, new GNOME |
39 |
betas, e17 packages, etc... |
40 |
-mike |
41 |
-- |
42 |
gentoo-dev@g.o mailing list |