Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Tom Wijsman]

On Sat, 15 Feb 2014 14:30:21 +0100
Jeroen Roovers <jer@g.o> wrote:

> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman <TomWij@g.o> 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@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D