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