1 |
On Thu, Aug 29, 2013 at 1:17 PM, Pacho Ramos <pacho@g.o> wrote: |
2 |
> At least from a gnome perspective, we are having some important delays |
3 |
> with some arches: |
4 |
> - Pending keyword requests: |
5 |
> https://bugs.gentoo.org/show_bug.cgi?id=351931 -> sh and sparc |
6 |
> https://bugs.gentoo.org/show_bug.cgi?id=478254 -> alpha,arm, ia64, ppc*, |
7 |
> sparc |
8 |
> https://bugs.gentoo.org/show_bug.cgi?id=478256 -> the same |
9 |
> https://bugs.gentoo.org/show_bug.cgi?id=387959 -> sh, sparc |
10 |
> https://bugs.gentoo.org/show_bug.cgi?id=469722 -> s390 (this is probably |
11 |
> the worst case as they are then having a buggy old version) |
12 |
> https://bugs.gentoo.org/show_bug.cgi?id=469982 -> s390 |
13 |
> https://bugs.gentoo.org/show_bug.cgi?id=471752 -> alpha, ia64, ppc*, |
14 |
> sparc |
15 |
> https://bugs.gentoo.org/show_bug.cgi?id=472510 -> s390 |
16 |
> https://bugs.gentoo.org/show_bug.cgi?id=476710 -> alpha, arm, ia64, |
17 |
> ppc*, sh, sparc, x86 |
18 |
> https://bugs.gentoo.org/show_bug.cgi?id=478082 -> alpha, sparc |
19 |
> https://bugs.gentoo.org/show_bug.cgi?id=466560 -> s390 |
20 |
> |
21 |
|
22 |
So, s390 and m68k seem to be the biggest problems in this thread in |
23 |
general as far as specific examples go, but the list above has some |
24 |
very stale bugs from a number of the other minor archs. |
25 |
|
26 |
I really don't think this is a case of one-offs. Maybe gnome is |
27 |
especially problematic, but the problem seems to be larger than that. |
28 |
|
29 |
As I see it we really only have two sustainable options: |
30 |
|
31 |
1. Drop stable keywords on these arches wholesale. |
32 |
2. Allow maintainers to be more aggressive about dropping stable |
33 |
packages when bugs are not closed in a reasonable timeframe (say, 90 |
34 |
days). |
35 |
|
36 |
I suspect that #1 may be inevitable for some of these archs, but I'm |
37 |
certainly willing to try #2 first and see where that leaves us. I |
38 |
don't like the idea of maintainers having to maintain old versions of |
39 |
things like gnome because arch teams put in some time in years past |
40 |
but aren't interested in the newer version/etc. |
41 |
|
42 |
So, how about this as a policy: |
43 |
If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a |
44 |
pending STABLEREQ, for 90 days with archs CCed and otherwise ready to |
45 |
be stabilized, the maintainer can remove older stable versions of the |
46 |
package at their discretion. A package is considered ready to be |
47 |
stabilized if it has been in the tree for 30 days, and has no known |
48 |
major flaws on arches that upstream considers supported. |
49 |
|
50 |
Note that if upstream doesn't support an arch, then it falls to the |
51 |
arch team (and not the maintainer) to support that arch if they want |
52 |
it stable. |
53 |
|
54 |
If the problem is limited to particular groups of packages then the |
55 |
new policy would take care of itself - stable keywords would basically |
56 |
get dropped until we're down to a set of packages that the arch team |
57 |
can support. If the problem is more widespread, then the new policy |
58 |
will basically make stable unusable on that arch as system packages |
59 |
get dropped, in which case we're basically back to dropping stable |
60 |
keywords. |
61 |
|
62 |
Again, this has nothing to do with picking and choosing arches to |
63 |
support. This is about defining the responsibility of arch teams if |
64 |
they want to be considered stable. The stable policy is basically a |
65 |
contract between arch teams and maintainers, and both sides have to do |
66 |
their part to make it work. |
67 |
|
68 |
Rich |