| 1 |
On Tue, Apr 7, 2015 at 7:25 PM, Anthony G. Basile <blueness@g.o> wrote: |
| 2 |
> On 04/07/15 11:38, Michael Palimaka wrote: |
| 3 |
>> |
| 4 |
>> On 07/04/15 08:22, Matt Turner wrote: |
| 5 |
>>> |
| 6 |
>>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@g.o> wrote: |
| 7 |
>>>> |
| 8 |
>>>> For instance, in this topic I haven't seen any comment from |
| 9 |
>>>> alpha/ia64/sparc arch teams... |
| 10 |
>>> |
| 11 |
>>> I haven't commented because I don't honestly believe people care. |
| 12 |
>>> |
| 13 |
>>> I'm really disappointed that the discussion is entirely about creating |
| 14 |
>>> keyword-dropping policies and no one is asking whether there are |
| 15 |
>>> things we can do to make keyword/stable requests a more streamlined |
| 16 |
>>> process. But, that kind of thing seems to be par for the course on |
| 17 |
>>> this list. |
| 18 |
>> |
| 19 |
>> We've heard very little from arch teams at all, let alone proposals for |
| 20 |
>> improving the stabilisation process. That's the main reason this sort of |
| 21 |
>> topic keeps coming up. |
| 22 |
> |
| 23 |
> I don't want my silence to be misinterpreted regarding ppc and ppc64. For |
| 24 |
> those arches, I'm willing to trim back on stabilization, but I really don't |
| 25 |
> want to drop to ~ as we did for mips. In fact, I'm thinking of turning mips |
| 26 |
> itself back into a stable arches with just the @system packages being |
| 27 |
> candidates for stabilization. The reason I like this approach is when I |
| 28 |
> build stage3's I can control what I know will build (stable packages) vs the |
| 29 |
> latest packages added to the tree (~arch). Nothing is more painful than |
| 30 |
> have to manually intervene in a bunch of catalyst builds. Being able to |
| 31 |
> control what will be built via stable keywords saves time and effort. |
| 32 |
> |
| 33 |
|
| 34 |
Would you be willing to monitor stablereqs and for ones that you can't |
| 35 |
keep up with, go ahead and remove stable keywords proactively on your |
| 36 |
own? The main concern is that this is a lot of hassle for |
| 37 |
maintainers. If the arch team can keep up with maintainers either by |
| 38 |
stabilizing packages or unstabilizing them, I think that will satisfy |
| 39 |
everybody. |
| 40 |
|
| 41 |
Alternatively, we can just change the status of the arch in repoman. |
| 42 |
Then you can keep your stable keywords if you wish, but package |
| 43 |
maintainers can also break your stable depgraph. |
| 44 |
|
| 45 |
-- |
| 46 |
Rich |
Archives