Re: [gentoo-dev] Policy for late/slow stabilizations

[Nirbheek Chauhan <nirbheek@gentoo.org>]

On Sun, Jun 27, 2010 at 8:34 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> As many of you have already noticed, there are some arches that are quite
> slow on stabilizations. This leads to deprecated stabilizations e.g a
> package is stabilized after 60 days which makes that version of
> the specific package obsolete and not worth to stabilize anymore.
>
> I would suggest to introduce a new rule where a stabilization bug may close
> after 30 days. Arches that fail to stabilize it within this timeframe
> they will simply don't have this package stable for them.
>

I disagree that just 30 days is enough to make a package obsolete and
not worth stabilizing. Infact, I think you're suggesting the number in
jest. GNOME for instance has a 6 month cycle, and we stabilize 1-4
months after the release (depending on the bugs, and our manpower).
For instance, the current release is 2.30 (~arch, released in March
'10, added to tree just a month ago), the previous release was 2.28
(stable, released in Sept '09), but the stable version on every arch
except amd64/x86 is 2.26 (released in March '09). And that's OK since
it got stable updates for a long time after release, and works
wonderfully. In essence, GNOME packages don't become obsolete unless
it's been 2 years since they were released.

I'm saying that a 30 days rule is too strict for most packages and
herds. I don't think such a rule will fly very far. Even a 90 day rule
or a 6 month rule is too strict for GNOME packages. I personally
empathize with the needs of users enough that I (and most of the gnome
team) are willing to wait for arches that cannot handle stabilization
bugs. We really don't want our users to have a bad experience because
of *us*. We'll do whatever is in our power.



> Moreover, slow arches introduce another problem as well. If a package is
> marked stabled for their arch, but this package is quite old, and they fail to
> stabilize a new version, we ( as maintainers ) can't drop the very old
> ( and obsolete ) version of this package because we somehow will break
> the stable tree for these arches. How should we act in this case?
> Keep the old version around forever just to say that "hey, they do have
> a stable version for our exotic arch".
>

Now *this* is a problem. We have some bugs, some security bugs that
have been completely ignored by some arches. Mips as usual is one, but
recently hppa (and to a much lesser extent, ppc64) have become slow.

To fix this, I suggest the following heuristic:

* If an arch cannot stabilize *security bugs* after 3 months, the
maintainers are free to drop the vulnerable version.
* If an arch cannot stabilize versions which fix major bugs after 6
months, the maintainers are free to drop the broken version.
* If an arch cannot stabilize a feature/minor bugfix stable request
after 12 months, the maintainers can nuke stable keywords from their
package.

In all cases, the time is to be counted from the original
stabilization request. Exceptions may be made in case newer
stabilization requests add extra dependencies to be stabilized.

Similar (but laxer) rules can be made for KEYWORDREQ bugs as well.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team