From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 047E513832E for ; Mon, 15 Aug 2016 17:32:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DA19B21C088; Mon, 15 Aug 2016 17:31:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E00AC21C038 for ; Mon, 15 Aug 2016 17:31:56 +0000 (UTC) Received: from localhost (unknown [100.42.103.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: williamh) by smtp.gentoo.org (Postfix) with ESMTPSA id 549AA340FB5 for ; Mon, 15 Aug 2016 17:31:55 +0000 (UTC) Date: Mon, 15 Aug 2016 12:31:30 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree Message-ID: <20160815173130.GA21750@whubbs1.gaikai.biz> Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <6046d13b-1a54-aa5e-ab16-df448b0f8c59@gentoo.org> <1471248012.31785.32.camel@gentoo.org> <20160815141922.GA3878@linux1.gaikai.biz> <1bff7eb3-cc91-bba7-1f7f-9e7f76906df3@gentoo.org> <20160815161241.GA21389@whubbs1.gaikai.biz> 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; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <20160815161241.GA21389@whubbs1.gaikai.biz> User-Agent: Mutt/1.5.24 (2015-08-30) X-Archives-Salt: 1ca497cb-cca3-4f61-b5ca-4cf261ce86ce X-Archives-Hash: fecf2ce57fcca913bbdce616831080c2 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I want to elaborate a bit more on this. On Mon, Aug 15, 2016 at 11:12:41AM -0500, William Hubbs wrote: > On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote: > > On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote: > > > On 08/15/2016 04:19 PM, William Hubbs wrote: > > >> I'm very much for this as well. Themaintainer should be able to > > >> stabilize on all arches after the timeout. That would solve the prim= ary > > >> concern I have about the stable tree lagging. > > >=20 > > > It depends on the context, if it is not security related or fixing a > > > known bug, it can cause regression for stable users without much gain. The maintainer of the package is going to have the most intimate knowledge = about these types of issues in the package, so I would rather have the maintainer make these types of decisions instead of restricting him with some global p= olicy. > >=20 > > Elaborating on this, if we're talking about maintainer stabilizing it > > after testing it properly there is no issue, but there shouldn't be a > > policy to auto-mark stable >=20 > As a maintainer, if there is an old version of a package in stable for > some arch and I have a stable request open for a newer version and the > arch team doesn't respond to the stable request within a reasonable > amount of time, I want to do one of two things: >=20 > - destabilize all versions of the package on this arch. That would allow > me to move on and take the worry about stabilizing this package off of > the arch team in the future. or > - if there are no blockers, stabilize the new version and deal with the > fallout myself if there is any. >=20 > If there is not an old version of the package marked stable, closing the > stablereq and moving on is probably what I would do after a certain > amount of time. >=20 > Maintaining a viable stable tree is a team effort between the > maintainers and the arch teams. If the arch teams are so overwhelmed > with stable requests that they can't keep things current, the > maintainers should be able to stabilize the newer versions and deal with > the fallout as a last resort, or decide that they don't want their > packages stable on those arches until the arch teams can keep up. >=20 > William >=20 --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlex/GwACgkQblQW9DDEZTjWZwCgubkR5xG/MUU+pQsEniEamNkQ xfgAoIO3EIeqtm8gCSvvU/0C5ayKBPUX =OALx -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+--