From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1L6vGa-0008D8-Ao for garchives@archives.gentoo.org; Sun, 30 Nov 2008 22:59:52 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 036EDE06F7; Sun, 30 Nov 2008 22:59:50 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B609BE06F7 for ; Sun, 30 Nov 2008 22:59:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 2F04264289 for ; Sun, 30 Nov 2008 22:59:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 required=5.5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIb28imGZdjV for ; Sun, 30 Nov 2008 22:59:43 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 41651644BC for ; Sun, 30 Nov 2008 22:59:42 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L6vGM-000404-B6 for gentoo-dev@gentoo.org; Sun, 30 Nov 2008 22:59:38 +0000 Received: from s0106001f3b27dbf9.mj.shawcable.net ([70.64.208.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Nov 2008 22:59:38 +0000 Received: from dirtyepic by s0106001f3b27dbf9.mj.shawcable.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Nov 2008 22:59:38 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Ryan Hill Subject: [gentoo-dev] Re: Proposal for how to handle stable ebuilds Date: Sun, 30 Nov 2008 16:59:35 -0600 Message-ID: <20081130165935.276a512c@halo.dirtyepic.sk.ca> References: <20081110181334.GD7038@aerie.halcy0n.com> 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="Sig_/LqtcuCvkMRH3GJC+qm/x+bc"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: s0106001f3b27dbf9.mj.shawcable.net X-Newsreader: Claws Mail 3.6.1 (GTK+ 2.14.5; x86_64-pc-linux-gnu) Sender: news X-Archives-Salt: bfb32f85-5c78-4e9f-adc2-a92837e5e90a X-Archives-Hash: 9e7104d5f001ea17486980f050614931 --Sig_/LqtcuCvkMRH3GJC+qm/x+bc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 10 Nov 2008 13:13:34 -0500 Mark Loeser wrote: > Instead of addressing archs as being slackers or not, this addresses > it as a more granular layer of looking at ebuilds. Thanks to Richard > Freeman for the initial proposal that I based this off of. Please > give me feedback on this proposal, if you think it sucks (preferably > with an explanation why), or if you think it might work. >=20 > Ebuild Stabilization Time >=20 > Arch teams will normally have 30 days from the day a bug was filed, > keyworded STABLEREQ, the arch was CCed, and the maintainer either > filed the bug or commented that it was OK to stabilize (clock starts > when all of these conditions are met). >=20 > Security bugs are to be handled by the policies the Security Team has > established. >=20 > Technical Problems with Ebuild Revisions >=20 > If an arch team finds a technical problem with an ebuild preventing > stabilization, a bug will be logged as a blocker for the keyword > request. The bug being resolved resets the time for the 30 days the > arch team has to mark the ebuild stable. >=20 > Removing Stable Ebuilds >=20 > If an ebuild meets the time criteria above, and there are no > technical issues preventing stabilization, then the maintainer MAY > choose to delete an older version even if it is the most recent > stable version for a particular arch. >=20 > If an ebuild meets the time criteria above, but there is a technical > issue preventing stabilization, and there are no outstanding security > issues, then the maintainer MUST not remove the highest-versioned > stable ebuild for any given arch without the approval of the arch > team. >=20 > Security issues are to be handled by the recommendations of the > Security Team. >=20 > Spirit of Cooperation >=20 > Ebuild maintainer and arch teams are encouraged to work together for > the sake of each other and end users in facilitating the testing and > maintenance of ebuilds on obscure hardware, or where obscure > expertise is needed. Package maintainers are encouraged to use > discretion when removing ebuilds in accordance with this policy. Since I completely stalled out this conversation I guess it's only fair that I try to restart it. I'm in favor of the above. I know it's not directly related to stabilization, but lately people have been removing the only keyworded package for the mips arch, under the excuse that's it's been over 30 days since they opened a keywording bug. This has been happening on bugs where there are technical issues and on bugs where we just haven't replied (in which case i can see the justification). I don't think this is acceptable, just as I don't think removing the only stable version of a package on an arch is be acceptable, barring the circumstances Mark outlined above. Yes? No? Get out of our treehouse? --=20 gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 --Sig_/LqtcuCvkMRH3GJC+qm/x+bc Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkzGtcACgkQiqiDRvmkBmIRTACgkY/dZtL7Uf/tECKlK6IftVPH AFMAoOphnzqyGLVB4UY6m2yHtBEeceeR =a2S3 -----END PGP SIGNATURE----- --Sig_/LqtcuCvkMRH3GJC+qm/x+bc--