1 |
On Wed, Apr 08, 2015 at 09:33:39AM -0400, Rich Freeman wrote: |
2 |
> Well, we really have a few options as far as imposing changes from |
3 |
> outside the arch team goes (the arch team can clean up its own |
4 |
> depgraph, of course, but presumably we'd be taking action only if they |
5 |
> didn't). |
6 |
> |
7 |
> 1. We could make the arches dev/exp as you point out, and then allow |
8 |
> maintainers to just drop stable versions and break their depgraph. |
9 |
> |
10 |
> 2. We could keep the arches as stable, but then allow maintainers to |
11 |
> do massive keyword changes when they drop otherwise-stable versions. |
12 |
> That wouldn't break the depgraph, but it would mean that at random |
13 |
> times huge numbers of packages could have their keywords change. |
14 |
|
15 |
It seems like the only difference between these two options would be |
16 |
who is responsible for fixing the depgraph. Let me say why I'm thinking |
17 |
this. |
18 |
|
19 |
Suppose that foo-1 is stable everywhere and I'm looking at a stable |
20 |
request for foo-2. I'm passed 90 days since I assigned the arch teams to |
21 |
this stable request. Also, foo is unslotted. |
22 |
|
23 |
Removing foo-1, or moving it back to ~arch, is going to have the same affect |
24 |
for all arches where it was stable and foo-2 is not, so I'm thinking I |
25 |
may as well remove foo-1. |
26 |
|
27 |
The difference, for stable vs non-stable arches, is that I will get |
28 |
complaints from repoman when I remove foo-1 for stable arches and I |
29 |
should also fix those. |
30 |
|
31 |
Is this right? |
32 |
|
33 |
> Neither option is really ideal. I think that #1 is the lesser evil, |
34 |
> but that does mean that we need to make a distro-wide decision. The |
35 |
> advantage of #2 is that it basically is a NOP unless the arch team |
36 |
> actually reaches 90 days old. I think it is better to just have the |
37 |
> Council make a decision rather than kicking the can, but that said if |
38 |
> an arch team is willing to state clearly that they intend to |
39 |
> proactively clean up their depgraph and that they want to keep stable |
40 |
> keywords, I'm fine with checking back in a month rather than |
41 |
> de-stabilizing them next week. |
42 |
|
43 |
Option #2 really isn't a NOP. It would say that maintainers have |
44 |
permission to remove old stable versions of a package when arch teams |
45 |
take more than 90 days to respond to a stable request for a newer |
46 |
version of the package. |
47 |
|
48 |
Also, do we have to make a distro-wide decision about whether an arch is |
49 |
stable? I realize we have been the ones making those decisions, but I |
50 |
don't think there is a policy that requires us to. |
51 |
|
52 |
William |