Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Nirbheek Chauhan <nirbheek@g.o>
Subject: Re: Policy for late/slow stabilizations
Date: Mon, 28 Jun 2010 04:38:42 +0530
On Mon, Jun 28, 2010 at 3:08 AM, Markos Chandras <hwoarang@g.o> wrote:
> On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote:
>> 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.
>
> What if this version is the only one that is stabled for this arch. Can
> you imagine the possible breakage that this action might cause?
>
> The problem is exactly here.
>
> If a package has only one version stable for an exotic arch, you cannot
> drop it because:
>
> * you will break packages that depend on it
> * you will make users angry
>

I agree. I didn't mean to imply that these heuristics were in any way
complete. I wrote them in a hurry; I only wanted to give an idea of
what my opinion on the matter is. We can add the following:

* For each arch, stable keywords are to be removed from
vulnerable/broken versions one week after newer versions are
stabilized on that arch.
* If removing stable keywords will lead to a large cascading effect of
reverse dependencies losing stable keywords, the 3 month wait should
be extended to 6 months or 12 months depending on the brokenness and
no. of packages that will get their keywords dropped.
* Maintainers are free to wait as long as they wish for arches, the
above guidelines merely give a lower bound to the wait time.
* In extenuating circumstances (critical vulnerabilities, complete
brokenness, etc), with the permission of the QA team, the wait can be
shortened, but it should never be less than a month.

This means that old broken/vulnerable ebuilds are not visible to any
arches except those that are slow. And if an arch cannot take out the
time to stabilized a vulnerable and/or badly broken version for a full
year, there's nothing we can do. If this is a chronic problem, we
should consider marking the arch as "Experimental".

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team


References:
Policy for late/slow stabilizations
-- Markos Chandras
Re: Policy for late/slow stabilizations
-- Nirbheek Chauhan
Re: Policy for late/slow stabilizations
-- Markos Chandras
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Policy for late/slow stabilizations
Next by thread:
Automated Package Removal and Addition Tracker, for the week ending 2010-06-27 23h59 UTC
Previous by date:
Re: Policy for late/slow stabilizations
Next by date:
Automated Package Removal and Addition Tracker, for the week ending 2010-06-27 23h59 UTC


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.