On Sun, Jun 27, 2010 at 8:34 PM, Markos Chandras <hwoar...@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
