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 ) 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 ; Sun, 27 Jun 2010 20:29:43 +0000 (UTC) Received: by iwn3 with SMTP id 3so26569iwn.40 for ; 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: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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: Subject: Re: [gentoo-dev] Policy for late/slow stabilizations From: Nirbheek Chauhan 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 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