On Sat, 15 Feb 2014 14:30:21 +0100 Jeroen Roovers <[email protected]> wrote:
> On Sat, 15 Feb 2014 11:41:57 +0100 > Tom Wijsman <[email protected]> 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 : [email protected] GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
