From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-dev+bounces-41599-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1OT0yI-0005js-5r
	for garchives@archives.gentoo.org; Sun, 27 Jun 2010 23:09:08 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 9D215E0ECB;
	Sun, 27 Jun 2010 23:09:02 +0000 (UTC)
Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181])
	by pigeon.gentoo.org (Postfix) with ESMTP id AD646E0EBF
	for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jun 2010 23:08:42 +0000 (UTC)
Received: by iwn3 with SMTP id 3so106787iwn.40
        for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jun 2010 16:08:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:sender:received
         :in-reply-to:references:date:x-google-sender-auth:message-id:subject
         :from:to:content-type;
        bh=p5x6/Sfr8gzxGUofOHYAfQawlnH+ExTNwgDQJXABQx0=;
        b=HqVyAe2VQXucExckLapXE3yOPXac+o85C2bUmyDDtML1to29AJ87NFrMUSmTNOcglU
         gqb3xVdsy+j+y87goKZ9zIx5QXLURWtbiNiy4aWqaBrfbG+X/50iWzkWoFe32SkBLnGQ
         M6SNsTPdubaP0Qqdyxwqehqb2R+xkdCD4WCBo=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=tRlejoK2eb6KbKbSm0SzCWiw/tcWH9KiH62aBt7aZf1LRwuRXbIJKhlR4gU3A9OMyI
         nW6JxN1k/AjWx5iVmCrQURuJAtcN8jeL40qIb+BwIJxZSiyqPsnDknMWMsw2TptOowlV
         Dvd+HwQOuFIJt01Ee29EhKCdL0qvPxUJeqNIE=
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.231.36.13 with SMTP id r13mr4428734ibd.50.1277680122359; Sun, 
	27 Jun 2010 16:08:42 -0700 (PDT)
Sender: nirbheek.chauhan@gmail.com
Received: by 10.231.150.68 with HTTP; Sun, 27 Jun 2010 16:08:42 -0700 (PDT)
In-Reply-To: <20100627213829.GA31454@Eternity>
References: <20100627150445.GA19456@Eternity>
	<AANLkTim4vP0pChgNp8R6vueokdrxcGqzJvFO6Z6IgXpI@mail.gmail.com>
	<20100627213829.GA31454@Eternity>
Date: Mon, 28 Jun 2010 04:38:42 +0530
X-Google-Sender-Auth: Bhb-IWqPQWjhSnzqBZDe-lUuQHE
Message-ID: <AANLkTikhaE2HAIvDHTSjn14jYz_QnF1JGDmfD1RXHQqd@mail.gmail.com>
Subject: Re: [gentoo-dev] Policy for late/slow stabilizations
From: Nirbheek Chauhan <nirbheek@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 19e5429b-af37-425b-9b6f-8b090eff2f1d
X-Archives-Hash: b55a69e19e4949b26d2f041195f8adfb

On Mon, Jun 28, 2010 at 3:08 AM, Markos Chandras <hwoarang@gentoo.org> 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