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-41596-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1OSyUE-0006i1-Lq
for garchives@archives.gentoo.org; Sun, 27 Jun 2010 20:29:54 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id D2F9DE0DFF;
Sun, 27 Jun 2010 20:29:51 +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 3A89DE0DE9
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jun 2010 20:29:43 +0000 (UTC)
Received: by iwn3 with SMTP id 3so26569iwn.40
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jun 2010 13:29: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=6SCmlYMtl0MOskyx6izBKqwfVi/gP4OEwGVgwvCvVIA=;
b=A6KhxCU4rAK4wa7D2+gP9KENeuXcKlCWt5RTKRqd9Qt4gjDyVfaW0Gr/G6/ZkAdlx+
aSDEtZETvNSLbz9M1Ih0UXc3plOIfueTKdyk6EzsCmaDfi3gLWiSqjWEgLscBmefrLpH
Fc261jKdfXLTO4tC4t+QdiDSESrZ6WVHIi/MQ=
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=Rr9yZMT4Ev6PNxISadQbcJe73EYBa1TNQv+TpxgtN9SLmZTYRA2+dIYDltQ1+qsLKO
HNWLk33ET82yIZbv3o1nTFygFtana6ve1gjukIe3JBgy2xQSElt4fjCDAFL+Cb0wUNOh
eJjVWIkIwcnzSg0FTO3I2BeJL3MBB18oTQIU0=
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.39.195 with SMTP id h3mr2044955ibe.71.1277670582574; Sun,
27 Jun 2010 13:29:42 -0700 (PDT)
Sender: nirbheek.chauhan@gmail.com
Received: by 10.231.150.68 with HTTP; Sun, 27 Jun 2010 13:29:42 -0700 (PDT)
In-Reply-To: <20100627150445.GA19456@Eternity>
References: <20100627150445.GA19456@Eternity>
Date: Mon, 28 Jun 2010 01:59:42 +0530
X-Google-Sender-Auth: FBT1jpEtRK20jKCccnMxH-LFUgs
Message-ID: <AANLkTim4vP0pChgNp8R6vueokdrxcGqzJvFO6Z6IgXpI@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: cd541cb3-1ce7-44cb-a846-78e4e7a71174
X-Archives-Hash: b5e434dae3fbf86db8ef26e8eb17019b
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