1 |
On 04/07/15 19:29, Rich Freeman wrote: |
2 |
> On Tue, Apr 7, 2015 at 7:25 PM, Anthony G. Basile <blueness@g.o> wrote: |
3 |
>> On 04/07/15 11:38, Michael Palimaka wrote: |
4 |
>>> On 07/04/15 08:22, Matt Turner wrote: |
5 |
>>>> On Mon, Apr 6, 2015 at 1:52 PM, Pacho Ramos <pacho@g.o> wrote: |
6 |
>>>>> For instance, in this topic I haven't seen any comment from |
7 |
>>>>> alpha/ia64/sparc arch teams... |
8 |
>>>> I haven't commented because I don't honestly believe people care. |
9 |
>>>> |
10 |
>>>> I'm really disappointed that the discussion is entirely about creating |
11 |
>>>> keyword-dropping policies and no one is asking whether there are |
12 |
>>>> things we can do to make keyword/stable requests a more streamlined |
13 |
>>>> process. But, that kind of thing seems to be par for the course on |
14 |
>>>> this list. |
15 |
>>> We've heard very little from arch teams at all, let alone proposals for |
16 |
>>> improving the stabilisation process. That's the main reason this sort of |
17 |
>>> topic keeps coming up. |
18 |
>> I don't want my silence to be misinterpreted regarding ppc and ppc64. For |
19 |
>> those arches, I'm willing to trim back on stabilization, but I really don't |
20 |
>> want to drop to ~ as we did for mips. In fact, I'm thinking of turning mips |
21 |
>> itself back into a stable arches with just the @system packages being |
22 |
>> candidates for stabilization. The reason I like this approach is when I |
23 |
>> build stage3's I can control what I know will build (stable packages) vs the |
24 |
>> latest packages added to the tree (~arch). Nothing is more painful than |
25 |
>> have to manually intervene in a bunch of catalyst builds. Being able to |
26 |
>> control what will be built via stable keywords saves time and effort. |
27 |
>> |
28 |
> Would you be willing to monitor stablereqs and for ones that you can't |
29 |
> keep up with, go ahead and remove stable keywords proactively on your |
30 |
> own? The main concern is that this is a lot of hassle for |
31 |
> maintainers. If the arch team can keep up with maintainers either by |
32 |
> stabilizing packages or unstabilizing them, I think that will satisfy |
33 |
> everybody. |
34 |
> |
35 |
> Alternatively, we can just change the status of the arch in repoman. |
36 |
> Then you can keep your stable keywords if you wish, but package |
37 |
> maintainers can also break your stable depgraph. |
38 |
> |
39 |
|
40 |
We had a couple of ideas in this direction. One is a "weak" |
41 |
stabilization criterion for ppc/ppc64. If the package builds for amd64, |
42 |
go ahead and mark ppc/ppc64 stable as well. This is bound to hit |
43 |
problems but we'll catch them after the fact. Another idea was to |
44 |
generate a list of packages we want to target as stable on ppc/ppc64 and |
45 |
drop stable keywords on all but those packages, then continue as we do |
46 |
now. Your idea Rich is actually a variation on this in that we can just |
47 |
unstabilize as we go along rather than generating the list and doing it |
48 |
all at once. That might be workable. |
49 |
|
50 |
What's holding me back right now is that when the ppc/ppc64 team met |
51 |
last year we said we were going to keep going as we have been. I'm |
52 |
hoping ppc/ppc64 can meet again soon and readdress this issue. |
53 |
|
54 |
-- |
55 |
Anthony G. Basile, Ph.D. |
56 |
Gentoo Linux Developer [Hardened] |
57 |
E-Mail : blueness@g.o |
58 |
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA |
59 |
GnuPG ID : F52D4BBA |