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

[William Hubbs]

On Sat, Feb 15, 2014 at 02:30:21PM +0100, Jeroen Roovers 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? 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?
 
 This is a good question; they probably don't.

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

This was my thinking when I started this thread, but the other side is
that once something is stable it shouldn't be touched until A newer
version of the package is stable.

As a maintainer, my thought is like this. If an arch team stabilizes a
version of a package I maintain, they are now committed to stabilizing
newer versions of that package in a reasonable time of when I request
them, or they need to respond to the stabilization bug within a
reasonable amount of time and tell me why they can't stabilize the newer
version so we can fix it. If they can't do either of these things, the
package doesn't need to be stable on their arch.

William