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 23:09:08
In Reply to: Re: [gentoo-dev] Policy for late/slow stabilizations by Markos Chandras
1 On Mon, Jun 28, 2010 at 3:08 AM, Markos Chandras <hwoarang@g.o> wrote:
2 > On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote:
3 >> Now *this* is a problem. We have some bugs, some security bugs that
4 >> have been completely ignored by some arches. Mips as usual is one, but
5 >> recently hppa (and to a much lesser extent, ppc64) have become slow.
6 >>
7 >> To fix this, I suggest the following heuristic:
8 >>
9 >> * If an arch cannot stabilize *security bugs* after 3 months, the
10 >> maintainers are free to drop the vulnerable version.
11 >
12 > What if this version is the only one that is stabled for this arch. Can
13 > you imagine the possible breakage that this action might cause?
14 >
15 > The problem is exactly here.
16 >
17 > If a package has only one version stable for an exotic arch, you cannot
18 > drop it because:
19 >
20 > * you will break packages that depend on it
21 > * you will make users angry
22 >
24 I agree. I didn't mean to imply that these heuristics were in any way
25 complete. I wrote them in a hurry; I only wanted to give an idea of
26 what my opinion on the matter is. We can add the following:
28 * For each arch, stable keywords are to be removed from
29 vulnerable/broken versions one week after newer versions are
30 stabilized on that arch.
31 * If removing stable keywords will lead to a large cascading effect of
32 reverse dependencies losing stable keywords, the 3 month wait should
33 be extended to 6 months or 12 months depending on the brokenness and
34 no. of packages that will get their keywords dropped.
35 * Maintainers are free to wait as long as they wish for arches, the
36 above guidelines merely give a lower bound to the wait time.
37 * In extenuating circumstances (critical vulnerabilities, complete
38 brokenness, etc), with the permission of the QA team, the wait can be
39 shortened, but it should never be less than a month.
41 This means that old broken/vulnerable ebuilds are not visible to any
42 arches except those that are slow. And if an arch cannot take out the
43 time to stabilized a vulnerable and/or badly broken version for a full
44 year, there's nothing we can do. If this is a chronic problem, we
45 should consider marking the arch as "Experimental".
47 --
48 ~Nirbheek Chauhan
50 Gentoo GNOME+Mozilla Team