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 1Nw9RR-0002dd-DQ for garchives@archives.gentoo.org; Mon, 29 Mar 2010 07:31:21 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 77AEBE07E3; Mon, 29 Mar 2010 07:31:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 6A16AE079F for ; Mon, 29 Mar 2010 07:30:55 +0000 (UTC) Received: from [192.168.1.35] (unknown [77.246.104.171]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 159F81B4061 for ; Mon, 29 Mar 2010 07:30:53 +0000 (UTC) Subject: Re: [gentoo-dev] [RFC] Reworking package stabilization policies From: Peter Volkov To: gentoo-dev@lists.gentoo.org In-Reply-To: <201003280747.28790.reavertm@gmail.com> References: <20100327205841.GA12996@linux1> <201003280747.28790.reavertm@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 29 Mar 2010 11:30:38 +0400 Message-ID: <1269847838.24530.80.camel@tablet> 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 X-Mailer: Evolution 2.28.3.1 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 0697ca4e-2751-4e57-950e-e4b17a69d515 X-Archives-Hash: 66cfa4d438379a35e57b1c629c20f238 =D0=92 =D0=92=D1=81=D0=BA, 28/03/2010 =D0=B2 07:47 +0200, Maciej Mrozowsk= i =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > No, seriously - given the fact that some of my packages were even stabi= lized=20 > without contacting me (app-misc/hal-cups-utils, app-admin/system-config= - > printer-common)=20 If you know packages are broken why they were not hardmasked? If they have no problems what why it was bad idea to mark them stable? > * solely up to the package maintainers to stabilize application on arch= es=20 > they're using or on any arch if package is arch-agnostic (optionally, b= ut=20 > preferably with some peer review from other project members or arch tea= m=20 > members). In general package maintainer should avoid to stabilize the packages he worked on as one of the arch team's goal was to have second eyes on package before it goes stable. > Role of arch teams would be decreased to peer review and solving KEYWOR= D=20 > requests. >=20 > It's really freaking silly to wait months for stabilization of some ran= dom=20 > php/perl library that's known to work. Why wait? amd64 team requested help and every developer who tested package on stable profile is allowed to mark package stable. For rare archs it's possible configure search filters to avoid stabilization requests. --=20 Peter.