Gentoo Archives: gentoo-dev

From: Nirbheek Chauhan <nirbheek@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Policy for late/slow stabilizations
Date: Sun, 27 Jun 2010 20:29:54
In Reply to: [gentoo-dev] Policy for late/slow stabilizations by Markos Chandras
1 On Sun, Jun 27, 2010 at 8:34 PM, Markos Chandras <hwoarang@g.o> wrote:
2 > As many of you have already noticed, there are some arches that are quite
3 > slow on stabilizations. This leads to deprecated stabilizations e.g a
4 > package is stabilized after 60 days which makes that version of
5 > the specific package obsolete and not worth to stabilize anymore.
6 >
7 > I would suggest to introduce a new rule where a stabilization bug may close
8 > after 30 days. Arches that fail to stabilize it within this timeframe
9 > they will simply don't have this package stable for them.
10 >
12 I disagree that just 30 days is enough to make a package obsolete and
13 not worth stabilizing. Infact, I think you're suggesting the number in
14 jest. GNOME for instance has a 6 month cycle, and we stabilize 1-4
15 months after the release (depending on the bugs, and our manpower).
16 For instance, the current release is 2.30 (~arch, released in March
17 '10, added to tree just a month ago), the previous release was 2.28
18 (stable, released in Sept '09), but the stable version on every arch
19 except amd64/x86 is 2.26 (released in March '09). And that's OK since
20 it got stable updates for a long time after release, and works
21 wonderfully. In essence, GNOME packages don't become obsolete unless
22 it's been 2 years since they were released.
24 I'm saying that a 30 days rule is too strict for most packages and
25 herds. I don't think such a rule will fly very far. Even a 90 day rule
26 or a 6 month rule is too strict for GNOME packages. I personally
27 empathize with the needs of users enough that I (and most of the gnome
28 team) are willing to wait for arches that cannot handle stabilization
29 bugs. We really don't want our users to have a bad experience because
30 of *us*. We'll do whatever is in our power.
34 > Moreover, slow arches introduce another problem as well. If a package is
35 > marked stabled for their arch, but this package is quite old, and they fail to
36 > stabilize a new version, we ( as maintainers ) can't drop the very old
37 > ( and obsolete ) version of this package because we somehow will break
38 > the stable tree for these arches. How should we act in this case?
39 > Keep the old version around forever just to say that "hey, they do have
40 > a stable version for our exotic arch".
41 >
43 Now *this* is a problem. We have some bugs, some security bugs that
44 have been completely ignored by some arches. Mips as usual is one, but
45 recently hppa (and to a much lesser extent, ppc64) have become slow.
47 To fix this, I suggest the following heuristic:
49 * If an arch cannot stabilize *security bugs* after 3 months, the
50 maintainers are free to drop the vulnerable version.
51 * If an arch cannot stabilize versions which fix major bugs after 6
52 months, the maintainers are free to drop the broken version.
53 * If an arch cannot stabilize a feature/minor bugfix stable request
54 after 12 months, the maintainers can nuke stable keywords from their
55 package.
57 In all cases, the time is to be counted from the original
58 stabilization request. Exceptions may be made in case newer
59 stabilization requests add extra dependencies to be stabilized.
61 Similar (but laxer) rules can be made for KEYWORDREQ bugs as well.
63 --
64 ~Nirbheek Chauhan
66 Gentoo GNOME+Mozilla Team


Subject Author
Re: [gentoo-dev] Policy for late/slow stabilizations Markos Chandras <hwoarang@g.o>