Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10
Date: Sun, 15 Sep 2013 15:03:34
Message-Id: CAGfcS_=fxoya+1v-cx4QZBVhigHj1w9p9bSxwvdXuUyYSynEDQ@mail.gmail.com
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting 2013-09-10 by Pacho Ramos
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

Replies