| 1 |
On 04/07/15 11:38, Michael Palimaka wrote: |
| 2 |
> On 07/04/15 08:22, Matt Turner wrote: |
| 3 |
>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@g.o> wrote: |
| 4 |
>>> For instance, in this topic I haven't seen any comment from |
| 5 |
>>> alpha/ia64/sparc arch teams... |
| 6 |
>> I haven't commented because I don't honestly believe people care. |
| 7 |
>> |
| 8 |
>> I'm really disappointed that the discussion is entirely about creating |
| 9 |
>> keyword-dropping policies and no one is asking whether there are |
| 10 |
>> things we can do to make keyword/stable requests a more streamlined |
| 11 |
>> process. But, that kind of thing seems to be par for the course on |
| 12 |
>> this list. |
| 13 |
> We've heard very little from arch teams at all, let alone proposals for |
| 14 |
> improving the stabilisation process. That's the main reason this sort of |
| 15 |
> topic keeps coming up. |
| 16 |
> |
| 17 |
> |
| 18 |
|
| 19 |
I don't want my silence to be misinterpreted regarding ppc and ppc64. |
| 20 |
For those arches, I'm willing to trim back on stabilization, but I |
| 21 |
really don't want to drop to ~ as we did for mips. In fact, I'm |
| 22 |
thinking of turning mips itself back into a stable arches with just the |
| 23 |
@system packages being candidates for stabilization. The reason I like |
| 24 |
this approach is when I build stage3's I can control what I know will |
| 25 |
build (stable packages) vs the latest packages added to the tree |
| 26 |
(~arch). Nothing is more painful than have to manually intervene in a |
| 27 |
bunch of catalyst builds. Being able to control what will be built via |
| 28 |
stable keywords saves time and effort. |
| 29 |
|
| 30 |
-- |
| 31 |
Anthony G. Basile, Ph.D. |
| 32 |
Gentoo Linux Developer [Hardened] |
| 33 |
E-Mail : blueness@g.o |
| 34 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
| 35 |
GnuPG ID : F52D4BBA |
Archives