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 D1ABC13832E for ; Thu, 4 Aug 2016 16:25:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0100DE0AA9; Thu, 4 Aug 2016 16:25:11 +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 68258E0AA8 for ; Thu, 4 Aug 2016 16:25:10 +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 77CB6340739 for ; Thu, 4 Aug 2016 16:25:09 +0000 (UTC) Date: Thu, 4 Aug 2016 11:24:43 -0500 From: William Hubbs To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 Message-ID: <20160804162443.GA7048@whubbs1.gaikai.biz> Mail-Followup-To: gentoo-project@lists.gentoo.org References: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Archives-Salt: 93c23db8-6d28-484e-83cd-606b8a7047d4 X-Archives-Hash: fb5d6fe4d6f84eeb5fedff2e968675fb --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 04, 2016 at 04:15:14PM +0200, Kristian Fiskerstrand wrote: > Dear all, >=20 > the Gentoo Council will meet again on Sunday, August 14 at 19:00 UTC > in #gentoo-council on FreeNode. >=20 > Please reply to this message on the gentoo-project list with any items > the council should put on its agenda to discuss or vote on. I feel that our stable tree is so far behind on all architectures that we are doing our stable users a disservice, so I would like to open up a discussion here, and maybe some policy changes at the next meeting. Ultimately, I think we need some form of automated stabilization, e.g. if a package version sits in ~ for 30 days and there are no blockers at that point, the new version should go automatically to stable on all architectures where there is a previous stable version. I realize that automation is going to take a lot of work, so in the meantime, I would like to discuss changes to our stabilization policies that will get new versions of packages to stable faster. The first issue is maintainers not filing stable requests for new versions of packages in a timely manor. I'm not sure how to get around this, but I feel that once a version of a package is stable, we are doing a disservice to our stable users by not keeping stable as current as possible. I am as bad as anyone; it is easy to forget to file stable requests until someone pings me or files the request themselves. I have heard other maintainers say specifically that they do not file stable requests unless a user asks them to, but Again, I do not feel comfortable with this arrangement if there is an old version of the package in stable. Users shouldn't have to ask for newer versions to be stabilized; this should be driven by the maintainers. The second issue is slow arch teams. Again, by not moving packages from ~ to stable, we are doing a disservice to our stable users. I can think of two ways we can improve our situation. We can allow maintainers to stabilize new versions of certain types of packages on all arches where there is a previous version of the package st= able without filing stable requests. This would take a significant load off of the arch teams. For packages that do not fit the first group, we could require stable requests, but allow maintainers to stabilize the new versions after a timeout (I would propose 30 days). What do folks think? William --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlejbEUACgkQblQW9DDEZThw6wCgsy2zLOsV0vEmQIUBxfOMZZEV f0wAn1UFMs7VWNvVhZUMcWfnxAGs/5Jr =oUXk -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--