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 9E8F413832E for ; Thu, 4 Aug 2016 21:30:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 60E66E0A61; Thu, 4 Aug 2016 21:30:25 +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 AAF88E090B for ; Thu, 4 Aug 2016 21:30:24 +0000 (UTC) Received: from [192.168.1.2] (c-73-53-75-119.hsd1.wa.comcast.net [73.53.75.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zlg) by smtp.gentoo.org (Postfix) with ESMTPSA id C451E340B7A for ; Thu, 4 Aug 2016 21:30:22 +0000 (UTC) Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 To: gentoo-project@lists.gentoo.org References: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org> <20160804162443.GA7048@whubbs1.gaikai.biz> From: Daniel Campbell Message-ID: <14962950-29f6-e7b4-19ba-9cdea15642a2@gentoo.org> Date: Thu, 4 Aug 2016 14:30:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 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 In-Reply-To: <20160804162443.GA7048@whubbs1.gaikai.biz> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xpKP42Ahb2N8I0NQCATNF00CPO5r56K3d" X-Archives-Salt: 6612c257-386e-41a5-88ee-d31c2fa53788 X-Archives-Hash: ba588e62249e7f776332d026669c39d2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xpKP42Ahb2N8I0NQCATNF00CPO5r56K3d Content-Type: multipart/mixed; boundary="nd34jpRquKMD8iviBaJEoeXSwx6XIoXxG" From: Daniel Campbell To: gentoo-project@lists.gentoo.org Message-ID: <14962950-29f6-e7b4-19ba-9cdea15642a2@gentoo.org> Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 References: <2e11e445-c25b-b7f2-def1-99aed92308b6@gentoo.org> <20160804162443.GA7048@whubbs1.gaikai.biz> In-Reply-To: <20160804162443.GA7048@whubbs1.gaikai.biz> --nd34jpRquKMD8iviBaJEoeXSwx6XIoXxG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/04/2016 09:24 AM, William Hubbs wrote: > On Thu, Aug 04, 2016 at 04:15:14PM +0200, Kristian Fiskerstrand wrote: >> Dear all, >> >> the Gentoo Council will meet again on Sunday, August 14 at 19:00 UTC >> in #gentoo-council on FreeNode. >> >> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > The second issue is slow arch teams. Again, by not moving packages from= > ~ to stable, we are doing a disservice to our stable users. >=20 > I can think of two ways we can improve our situation. >=20 > We can allow maintainers to stabilize new versions of certain types of > packages on all arches where there is a previous version of the packag= e stable > without filing stable requests. This would take a significant load off= > of the arch teams. >=20 > 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). >=20 > What do folks think? >=20 > William >=20 I can understand where you're coming from on this. Perhaps a more comprehensive, approachable guide could be written for newer maintainers like myself so we can learn a few of the skills the arch teams use to stabilize packages. Proposed testing environments and setups (for example, a VM dedicated to stabilization that runs on stable rather than using the dev's main machine) would be super helpful. Count me as one maintainer that'd love to learn how to do a better job maintaining and getting newer versions stabilized. As it stands, I'm almost afraid of pushing something to stable because I fear I'll miss something or piss somebody off because I didn't perform the right ritual beforehand or something. Perhaps a good way to approach it is to adopt a sort of "every maintainer is also an arch tester" ideology and get these skills passed down/out to everyone to lessen the load of the arch teams. --=20 Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 --nd34jpRquKMD8iviBaJEoeXSwx6XIoXxG-- --xpKP42Ahb2N8I0NQCATNF00CPO5r56K3d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXo7PoAAoJEAEkDpRQOeFwEDsP/33x8ddN1EaRggxCH2+6+29A /Zw+M5B7cgkm3ZsstJ1MTjD2BaWP3eIs2OjeVBG5JmBymPgaArnJPhZ0m8yuGz92 Ci+uqGl90hoKzXf0bfLV1IDajubd3gubh/FtBVBPzBYp0uvKV3cmIVcXFRnXraw0 ltXbWCgkMKZpWO3yE+4i5q95n4+0fCZ0euUHJpAa+TTuqWLk3jTFrYSb15RWFHEb g75xF+azMpnPkSv0QTKtkxK69EOp7KpnLTQXzEGVz6Kje0KaSVcycN+oO/YnpO1x b6K/NrrKyL6aoBspPI2IoiIbMVrWDEfsXFJrqiGOBXUwQfrAmZ5LbNfJYHK0H4yr pomZVWxwpwgJac1+6y8/ctVZbJKgWQpGozcvB6VQMGgSSNEbZkhVYwhDp5iOkRnW OQrD9RSC/gwdpERzt8qeu1lQItKcHOWGBmo/prXhb34tvsWsytOO25e5qxUxnuke ul8SjQLOaUZNlLMX7IklqeU9tSnSfjerTJZcmjiXYUbvrdLZasn1bcvuFG5mA5WL px3nONu0+xPC/lT4dj7V2lXQEXS2ajR/oonr1J5Tfti7p+YA+4PQGxqs+lRje1lg 3ojl5JKBiNPJm7wvWOgqmTMd+LxcuXoXXp2G84LNCeOKEAZyh9BDjU46pHMVAcwZ o51Awj/JJi22bH9ZGi4v =+iwJ -----END PGP SIGNATURE----- --xpKP42Ahb2N8I0NQCATNF00CPO5r56K3d--