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 BC717138BF3 for ; Sun, 16 Feb 2014 07:26:38 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A94DBE0AB0; Sun, 16 Feb 2014 07:23:38 +0000 (UTC) Received: from michel.telenet-ops.be (michel.telenet-ops.be [195.130.137.88]) by pigeon.gentoo.org (Postfix) with ESMTP id 98657E0A6C for ; Sun, 16 Feb 2014 07:23:37 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by michel.telenet-ops.be with bizsmtp id SvPc1n00W2khLEN06vPc5D; Sun, 16 Feb 2014 08:23:36 +0100 Date: Sun, 16 Feb 2014 08:23:27 +0100 From: Tom Wijsman To: jer@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords) Message-ID: <20140216082327.6f7b97ce@TOMWIJ-GENTOO> In-Reply-To: <20140215143021.231bab3f@marga.jer-c2.orkz.net> References: <52E7DBC1.5020102@gentoo.org> <20140128182304.7d458a17@marga.jer-c2.orkz.net> <20140203062524.GA7467@rathaus.eclipse.co.uk> <20140203104341.2add2760@TOMWIJ-GENTOO> <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> <20140215143021.231bab3f@marga.jer-c2.orkz.net> 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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 1736c34b-926e-4911-9c1f-2cb419c28899 X-Archives-Hash: 61378e91f812804367a4eb5c513fc22e On Sat, 15 Feb 2014 14:30:21 +0100 Jeroen Roovers wrote: > On Sat, 15 Feb 2014 11:41:57 +0100 > Tom Wijsman wrote: > > > > Assigning bugs so arch teams is cosmetic at best. > > s|so|to| > > > While it was not explained here, the idea can also move the actual > > maintenance of the ebuild to the arch team; such that it becomes the > > arch team's responsibility to deal with it, or rather don't deal > > with it > > How would that ever work? The responsibility is moved away from the maintainer; and thus also its bugs, as well as the need to rely on a newer version to become stable. > You have some old cat/pkg/pkg-version.ebuild that you no longer want > to maintain, but which happens to be the latest stable for $ARCH, > which is apparently understaffed because they $ARCH hasn't tended to > a related bug report in months, and now you want to leave the ebuild > in place and also expect $ARCH to start maintaining it? The entire paragraph that you quote answers this. > How does $ARCH have the man power to do that, again? This thread is about the problems resulting out of that. > > and have it act as a nagging reminder that stabilization really is > > due. This also reflects the importance of the package, as it will > > receive more attention and thus be more verbose towards the arch > > team. > > No, you're wrong there. Nobody is reading those bugzilla e-mails - > nobody is working on keywording/stabilisation for $ARCH. "Nagging" is > pointless when nobody hears you, and an e-mail from bugzilla isn't > magically better prioritised when Assignee: changes. The maintainer was reading these mails; this solution in main instance addresses the maintainer's problem, what the arch team does further with the bugs is their responsibility. They can /dev/null it if they feel like; but if they want to address it more useful, they can just as well use it as a measure of which packages really need a newer version stabilized. > The only reasonable course of action is to start dropping stable > keywords for $ARCH, after a reasonable timeout. It gets tricky if this > involves removing many keywords on dependencies, but if that's what > you have to do to keep cat/pkg (and eclasses and profiles) in shape, > then by all means _help_ _out_ $ARCH by doing it for them. If that > means removing stable/unstable support for an entire DM or scripting > framework, then so be it. There was a new QA policy in place to support this; but it has been brought back under discussion, as to address a wider acceptance further discussion is needed. That policy was allowing the maintainer to do so. > As long as @system is keyworded properly (by which I really really > really mean something better than a "compile only" test - you know who > you are), $ARCH users will normally be able to figure out how to > emerge unstable packages themselves. +1, more than @system would be nice, would love to see some kind of importance applied; it can still make sense to stabilize all the more common outside of @system that a lot of people use, but some plug-in of some less famous package could be left unstable. > > > Recently I've seen a few keywording/stabilisation bug reports > > > assigned to arch teams again. It's really annoying. If you've > > > started doing this, then please stop before people start to think > > > it's a good idea. It's not. > > > > Depends on what the arch teams think of this > > No, it doesn't. Package maintainers are responsible for their bug > reports, and Assignee: should reflect that. The package mainatiners have long fixed this (or found fixes) in newer versions of the package; their responsibility effectively ends at that point, and stabilization of newer versions is the arch team's responsibility. An arch team in Assignee: can do something about it. > Maintaining a stable tree for an arch team means that someone on that > team needs to do more than scratch their own itches - slacking should > be fixed by relieving their burden, not pile on more, because that's > precisely how volunteer work ultimately doesn't get done. By prioritizing their efforts by bug counts, and dropping off what is doesn't fit their slate; they can effectively relieve that burden. For the same reason, these shouldn't be kept assigned to maintainers, as piling old bugs on the maintainer's bugs lists is what blocks progress; as the bottleneck is in their bug list, instead of in that of the arch team where it is supposed to be and could be fixed or ditched. -- 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