| 1 |
On Friday 16 September 2005 04:44 pm, Ciaran McCreesh wrote: |
| 2 |
> On Fri, 16 Sep 2005 16:33:13 -0400 Mike Frysinger <vapier@g.o> |
| 3 |
> |
| 4 |
> wrote: |
| 5 |
> | ok, e17 packages dont count here. however, your hardcore view i |
| 6 |
> | still dont buy. how about the baselayout-1.9.x -> baselayout-1.11.x |
| 7 |
> | stabilization process ? are you telling me that arch teams should |
| 8 |
> | have had the power to move those into stable without talking to the |
| 9 |
> | maintainer ? baselayout may be a core package, but if you continue |
| 10 |
> | with your hard rule here, then it doesnt matter. |
| 11 |
> |
| 12 |
> I'm saying that arch teams should be allowed to mark it stable if they |
| 13 |
> think it's appropriate. Not that it must be moved to stable after $x |
| 14 |
> days, but that it can be at the arch team's discretion. And any arch |
| 15 |
> team which is silly enough to mark a broken baselayout stable has far |
| 16 |
> bigger problems anyway... |
| 17 |
|
| 18 |
baselayout is an example, any package can be used here (although not many are |
| 19 |
as critical) |
| 20 |
|
| 21 |
i'm saying that the maintainer may have a certain idea of when the package is |
| 22 |
ready for stable (a target feature set, working out certain quirks, etc...). |
| 23 |
your current hard view does not allow for that. for example, i had an arch |
| 24 |
maintainer one time mark bash-3 stable before base-system was ready for it |
| 25 |
(readline, baselayout, etc... were going to be stabilized together). i |
| 26 |
smacked them hard for it, but if we went with this hard view, it would have |
| 27 |
been perfectly acceptable behavior. |
| 28 |
-mike |
| 29 |
-- |
| 30 |
gentoo-dev@g.o mailing list |
Archives