From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id C2586138BF3 for ; Mon, 17 Feb 2014 18:47:05 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9BFE6E0ADC; Mon, 17 Feb 2014 18:46:59 +0000 (UTC) Received: from andre.telenet-ops.be (andre.telenet-ops.be [195.130.132.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 8A7BBE0ABE for ; Mon, 17 Feb 2014 18:46:58 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by andre.telenet-ops.be with bizsmtp id TWmx1n00u2khLEN01Wmxe0; Mon, 17 Feb 2014 19:46:57 +0100 Date: Mon, 17 Feb 2014 19:46:43 +0100 From: Tom Wijsman To: gentoo-dev@lists.gentoo.org Subject: Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords) Message-ID: <20140217194643.6f10d123@TOMWIJ-GENTOO> In-Reply-To: <20140216205041.GA22946@laptop.home> References: <20140204210319.GA1935@rathaus.eclipse.co.uk> <20140205010833.1bcf8dca@TOMWIJ-GENTOO> <20140213212818.GA2199@rathaus.eclipse.co.uk> <20140214195958.5aea85f0@TOMWIJ-GENTOO> <20140215012855.417f1caa@marga.jer-c2.orkz.net> <20140215114157.6abe3da5@TOMWIJ-GENTOO> <20140215225322.GB1593@laptop.home> <20140216003703.6ceb9116@marga.jer-c2.orkz.net> <1392540063.18051.95.camel@belkin5> <20140216185847.29cd1e71@TOMWIJ-GENTOO> <20140216205041.GA22946@laptop.home> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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; boundary="Sig_/vyz4FyPnuN3Z3eh+wwKQlRy"; protocol="application/pgp-signature" X-Archives-Salt: 6b44140a-be2c-4587-8233-1c073c7a21ea X-Archives-Hash: 9beb7e3e1ffbd1cd0a3ef8cda8e5486c --Sig_/vyz4FyPnuN3Z3eh+wwKQlRy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 16 Feb 2014 14:50:41 -0600 William Hubbs wrote: > On Sun, Feb 16, 2014 at 06:58:47PM +0100, Tom Wijsman wrote: > > On Sun, 16 Feb 2014 09:41:03 +0100 > > Pacho Ramos wrote: > >=20 > > > El dom, 16-02-2014 a las 00:37 +0100, Jeroen Roovers escribi=C3=B3: > > > [...] > > > > > If we want a separate assignee for old stabilizations, what > > > > > about a separate project that handles this, or maybe we could > > > > > assign the bugs to m-n or something until the arch teams > > > > > catch up? > > > >=20 > > > > Again, where is the man power for that? :-) > > > >=20 > > > > It's the maintainers that this problem hurts most, so they > > > > could and should be fixing it themselves - after a few months > > > > of waiting, reminding arch teams and gritting your teeth over > > > > it, just remove the old stable ebuilds[1]. > > > >=20 > > > >=20 > > > > jer > > > >=20 > > > >=20 > > > > [1] Where possible. If this happens with non-dev, > > > > non-experimental architectures and keeping the old ebuilds is a > > > > real problem, the architecture's status should be reconsidered. > > > > As has been done on this mailing list time and again. If an > > > > arch team cannot even be bothered to keep @system up to date, > > > > then why bother pretending it's anywhere near "stable"? > > > >=20 > > >=20 > > > I agree with Jeroen here. If the arch teams that are usually a bit > > > behind are not able to fix the bugs, I doubt we will gain anything > > > assigning bugs to them. Because of the way testing/stabilization > > > bugs work, arch teams should always check the bugs with them CCed > > > and, then, I don't think getting that bugs assigned to them would > > > change much. > >=20 > > That would be true if the context of this thread were the arch team; > > however, the context of this thread is the maintainer as that is the > > person experiencing the problem that was put forward. > >=20 > > The solution here thus intends to address the maintainer, which > > benefits from this; while it keeps the arch team's the same, > > whether the arch team does more with this is their own > > responsibility. > >=20 > > > Also, keeping the bugs assigned to package maintainers will still > > > allow them to try to get that pending bugs fixed (or resolved in > > > some way) as they will take care more about that specific package > > > status. > >=20 > > Package maintainers have better things to do. While it would allow > > for example the GNOME team to maintain GNOME 2 which sticks around; > > it actually happening is another story as they want to see GNOME 2 > > go, because maintaining multiple versions of GNOME costs too much > > time. > >=20 > > > If we get that bugs assigned to arch teams, they will likely be > > > ignored by both parts, getting worse. > >=20 > > At this point the arch team can realize that keeping the version > > around is an unrealistic goal, they can then take a decision to > > stop keeping it around and thus remove it; if needed, taking > > additional steps. >=20 > You are still assuming that the arch team is fully staffed. If they > are not, the old versions of packages still remain in the tree > indefinitely. It allows undermanned arch teams to prioritize; and as a consequence of that, the assumption is that arch team's are undermanned as the fully staffed arch teams benefit less from this. This is under the assumption that this is being put to good use by the arch team, but that's up to them; as I mentioned yesterday this is focused more on the maintainer. Ignoring this, I see what you are getting at in the second part of that paragraph; it indeed could become annoying to have to track which versions you are and no longer are maintaining, which adds another parameter of complexity to our daily maintenance work. > As a maintainer, at some point, I don't want them around. > > Keeping them around can force me to keep old migration code for > example that automates upgrading to new versions longer than I would > have to otherwise. +1 --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/vyz4FyPnuN3Z3eh+wwKQlRy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJTAlkXAAoJEPWZc8roOL/QLbsH/2zIkgae9/iEnJvt7C54YUFt f1nzDlsys/u/6bIgI3KopaEM96WVl/HOF4x4IsrQt1cG29nYWCbfdAO7HSHWAMTW /TRslQE+1S3c29OFAaelOGnZ+qhpyncKXpduGS1NXWS+P1iwE38R1ficJsje8TCI efK4l8bceXLFymPywOBZmqPfCTDdI7AOLusBTZ4/3hdV11y4CPC3t/E101/RWLTV OBeMeiEVL5ku2ZeMvqYTN01Ezop3CV01m21zdm7zUt4gtYH8sme4z6dkUSmU1mdW 6JTVnIh9a6L4OhV4krR2Fh8jmMn/l+XTYaDPPwg/nY7L2sM9fT+XTt+uNKWc/dU= =OdbZ -----END PGP SIGNATURE----- --Sig_/vyz4FyPnuN3Z3eh+wwKQlRy--