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

[Rich Freeman]

On Sat, Feb 15, 2014 at 8:30 AM, Jeroen Roovers <jer@g.o> wrote:
> On Sat, 15 Feb 2014 11:41:57 +0100
> Tom Wijsman <TomWij@g.o> wrote:
>
>> 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? 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? How does $ARCH have the man power to do that, again?

Many objected to removal since old with minor issues is better than
new that doesn't work at all on some archs, or so the argument goes.

This thread has gone on for a while, but at least this is a new suggestion.

If we were torn between these two options (removal or re-assignment),
then we could potentially leave the decision up to the arch team.  If
they speak up they can get bugs assigned to them, and if they don't
speak up they get their stable packages removed.

And I'm all for other options, but beyond more manpower I'm just not
seeing anything that is going to be pretty.

> 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.

I think the point is that the maintainer doesn't see the nags.  If
nobody else sees them either it is "somebody else's problem" from
their standpoint.  That isn't going to make the bug submitter very
happy, but if removal of the only version of a package that works on
their arch entirely is the alternative I suspect they will live with
it, or better still join the arch team.

Removing the package version entirely is the tidy solution from a
tracking/bugs/etc standpoint. The problem is that for the end user it
might mean taking away something that at least somewhat works and
leaving them with nothing.  Fixing the new version probably isn't an
option if somebody isn't willing to step up, so the question is just
whether we keep around the old version.  The new suggestion is to keep
it around, but not to bug the maintainer with the resulting issues.

If an old version gets to the point where it is simply unusable it
should almost certainly be dropped.  That at least avoids constantly
pestering the bug wranglers/etc with dups, and gives the arch team a
bug list where at least they have some hope of doing something.

Rich