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-41598-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1OSzay-0003Ui-0p
for garchives@archives.gentoo.org; Sun, 27 Jun 2010 21:40:56 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 0ECACE0E95;
Sun, 27 Jun 2010 21:40:51 +0000 (UTC)
Received: from mail-bw0-f53.google.com (mail-bw0-f53.google.com [209.85.214.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 62547E0E7A
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jun 2010 21:40:33 +0000 (UTC)
Received: by bwz6 with SMTP id 6so346652bwz.40
for <gentoo-dev@lists.gentoo.org>; Sun, 27 Jun 2010 14:40:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:sender:date:from:to:subject
:message-id:references:mime-version:content-type:content-disposition
:in-reply-to:user-agent;
bh=pBhrGcbrWPmWdeFqNKD8PzLMGv1jUMFUXEZ5GhtAWgI=;
b=c6ZFYVsaKRabg2Cs2k9saxFYzLd4zgUtjZaEG7B4YW5Mk//pHdmUbFocIZndSYHtw0
CkQY5netgahQanyi4xkvNzsRbl2jf1IewkHc0pMDN9jt1QhsH0lNONOx+LNB4yZrgODT
9rfeoqRz5s69wXtp6m+vxA1egH6r3GgejI6Nc=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=sender:date:from:to:subject:message-id:references:mime-version
:content-type:content-disposition:in-reply-to:user-agent;
b=d7HNqSyHVbulNhBDFytv661aX2knAs28L3stoV6oioNiPnYuMbdGK6eJta1X6dSDuw
IV2iNagfN6worABGOKHeW0Y5o406BJY2pD2fSI6yRlo6VhQz4hnVFSBS59P8FgDvknif
rduRwL/RlmfnlgObHQGztiRHz3bP2tyNhrV+c=
Received: by 10.204.47.98 with SMTP id m34mr815378bkf.95.1277674832725;
Sun, 27 Jun 2010 14:40:32 -0700 (PDT)
Received: from Eternity (79.103.24.94.dsl.dyn.forthnet.gr [79.103.24.94])
by mx.google.com with ESMTPS id u9sm13751192bkf.17.2010.06.27.14.40.31
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sun, 27 Jun 2010 14:40:32 -0700 (PDT)
Sender: Markos Chandras <markos.chandras@gmail.com>
Date: Mon, 28 Jun 2010 00:38:29 +0300
From: Markos Chandras <hwoarang@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Policy for late/slow stabilizations
Message-ID: <20100627213829.GA31454@Eternity>
References: <20100627150445.GA19456@Eternity>
<AANLkTim4vP0pChgNp8R6vueokdrxcGqzJvFO6Z6IgXpI@mail.gmail.com>
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
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk"
Content-Disposition: inline
In-Reply-To: <AANLkTim4vP0pChgNp8R6vueokdrxcGqzJvFO6Z6IgXpI@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Archives-Salt: 07ecf87f-f2b7-481b-9dbb-e5ba2ab1d197
X-Archives-Hash: 58e1e8cbf53094a686305580c6a37b9b
--qDbXVdCdHGoSgWSk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Jun 28, 2010 at 01:59:42AM +0530, Nirbheek Chauhan wrote:
>=20
> 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.
>=20
The '30 days' was just an example. Any reasonable timeframe could do
>=20
>=20
> > 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".
> >
>=20
> 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.
>=20
> To fix this, I suggest the following heuristic:
>=20
> * 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.=20
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
--=20
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org
--qDbXVdCdHGoSgWSk
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)
iEYEARECAAYFAkwnxNUACgkQ9/cejkQaxBCMIACeL+tyXftNlBW7fEg3Ye53sMS5
IbsAn0V4+khsdxMYLKWa4AUkPONYsBDH
=HhA/
-----END PGP SIGNATURE-----
--qDbXVdCdHGoSgWSk--