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 1OSwG8-0004gj-Ry for garchives@archives.gentoo.org; Sun, 27 Jun 2010 18:07:13 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 28BF5E0CF7; Sun, 27 Jun 2010 18:07:10 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id EF470E0CF4 for ; Sun, 27 Jun 2010 18:07:03 +0000 (UTC) Received: from afta-gentoo.localnet (ip-85-198-235-97.broker.com.pl [85.198.235.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPSA id 657611B402B for ; Sun, 27 Jun 2010 18:07:03 +0000 (UTC) From: Arfrever Frehtes Taifersar Arahesis To: Gentoo Development Subject: Re: [gentoo-dev] Policy for late/slow stabilizations Date: Sun, 27 Jun 2010 20:07:21 +0200 User-Agent: KMail/1.13.3 (Linux/2.6.32-tuxonice-r11-AFTA; KDE/4.4.4; x86_64; ; ) References: <20100627150445.GA19456@Eternity> In-Reply-To: <20100627150445.GA19456@Eternity> 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 Content-Type: multipart/signed; boundary="nextPart1380287.enqLGKKoLu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201006272007.23148.Arfrever@gentoo.org> X-Archives-Salt: c9c4cbb0-f7a5-4fbc-a61a-2f72fd226c79 X-Archives-Hash: a189598cd1fb11068f69b93ab710d94e --nextPart1380287.enqLGKKoLu Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 2010-06-27 17:04:45 Markos Chandras napisa=C5=82(a): > Hi >=20 > 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. >=20 > I would suggest to introduce a new rule where a stabilization bug may clo= se > after 30 days. Arches that fail to stabilize it within this timeframe > they will simply don't have this package stable for them. >=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 fa= il 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 > Whilst I do understand that these arches are understaffed and they can't = keep > up with the increased stabilization load like x86/amd64 do, I still > think that slow stabilization leads to an obsolete stable tree which I > doesn't make sense to me after all. >=20 > Thoughts? +1. The period of waiting might be extended to 60 days. This period should be counted from the first ignored stabilization request. Stabilizations of some packages are filed e.g. once per month and some architectures don't manage to stabilize older versions before stabilization requests of new versions. =2D-=20 Arfrever Frehtes Taifersar Arahesis --nextPart1380287.enqLGKKoLu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iQIcBAABAgAGBQJMJ5NbAAoJEFU3/w1zlLfg4CAP/1/NE7cvOpfHUpotbL+kQPub FJ/CFakeTX2h1+B/9AmI8DdtJ9l2fJH8piMQOw0xHzc/tGC8Jw9OXyLanMSOQpSS MfjLWIFoKGKFYJyuZnm1oe6H2m1ow8ZwAPhesrAUp5HWLUUKV53RnbeebGVbA4Vu tuXr13Cm4aZ9LC3QwYsHPWoqHyIVTxvL5s5C3r5Aw8tg0e8cZNvruJkOXaCvhA4y vPgB/j5JZXtAV1kNIxmdRo8xBDsEq6Y1I9EiKEWFtNGs96UPeAQ+29f7am/1Mahe q6S+zhl6FRliHIpuhFJiiIJjgJB6ybhLyd5FZJH/WS4zWIJj6OsJWBYnTlOMRVFi VabV7R+a+WRbEjQoO4fhOi7D+Ru7ZUoQC9BU3eViqjaFCTb17FiJ21YOjXxvrFD0 MIkR45/515WHXFKhTjOVyfvD12YljgzMFmhu4aei9bVC6+FkeeT2022ZCbnSQGQT t6Q+BztCmBcuGQ6apzJUHAqDihmyJvo0qr6LqTlNo1UDYdM5qtoW29C9kprxmoK6 SN7u0GJrvw4lxYyjuaiosGpUM7BXsxMzJCMkO7T2gIMFWi+D58MGvyCCu5R5LZL8 dDTBdGEuyalidwT+KkZHdAxQL5OjC4pvVTHeLhgyC344PurYoDpryw39j0FruGiu TRokhFaXvrxrPlhEncuq =HhlO -----END PGP SIGNATURE----- --nextPart1380287.enqLGKKoLu--