| 1 |
On Sat, 15 Feb 2014 11:41:57 +0100 |
| 2 |
Tom Wijsman <TomWij@g.o> wrote: |
| 3 |
|
| 4 |
> > Assigning bugs so arch teams is cosmetic at best. |
| 5 |
|
| 6 |
s|so|to| |
| 7 |
|
| 8 |
> While it was not explained here, the idea can also move the actual |
| 9 |
> maintenance of the ebuild to the arch team; such that it becomes the |
| 10 |
> arch team's responsibility to deal with it, or rather don't deal with |
| 11 |
> it |
| 12 |
|
| 13 |
How would that ever work? You have some old cat/pkg/pkg-version.ebuild |
| 14 |
that you no longer want to maintain, but which happens to be the latest |
| 15 |
stable for $ARCH, which is apparently understaffed because they $ARCH |
| 16 |
hasn't tended to a related bug report in months, and now you want to |
| 17 |
leave the ebuild in place and also expect $ARCH to start maintaining |
| 18 |
it? How does $ARCH have the man power to do that, again? |
| 19 |
|
| 20 |
> and have it act as a nagging reminder that stabilization really is |
| 21 |
> due. This also reflects the importance of the package, as it will |
| 22 |
> receive more attention and thus be more verbose towards the arch team. |
| 23 |
|
| 24 |
No, you're wrong there. Nobody is reading those bugzilla e-mails - |
| 25 |
nobody is working on keywording/stabilisation for $ARCH. "Nagging" is |
| 26 |
pointless when nobody hears you, and an e-mail from bugzilla isn't |
| 27 |
magically better prioritised when Assignee: changes. |
| 28 |
|
| 29 |
The only reasonable course of action is to start dropping stable |
| 30 |
keywords for $ARCH, after a reasonable timeout. It gets tricky if this |
| 31 |
involves removing many keywords on dependencies, but if that's what you |
| 32 |
have to do to keep cat/pkg (and eclasses and profiles) in shape, then |
| 33 |
by all means _help_ _out_ $ARCH by doing it for them. If that means |
| 34 |
removing stable/unstable support for an entire DM or scripting |
| 35 |
framework, then so be it. |
| 36 |
|
| 37 |
As long as @system is keyworded properly (by which I really really |
| 38 |
really mean something better than a "compile only" test - you know who |
| 39 |
you are), $ARCH users will normally be able to figure out how to emerge |
| 40 |
unstable packages themselves. |
| 41 |
|
| 42 |
> > Recently I've seen a few keywording/stabilisation bug reports |
| 43 |
> > assigned to arch teams again. It's really annoying. If you've |
| 44 |
> > started doing this, then please stop before people start to think |
| 45 |
> > it's a good idea. It's not. |
| 46 |
> |
| 47 |
> Depends on what the arch teams think of this |
| 48 |
|
| 49 |
No, it doesn't. Package maintainers are responsible for their bug |
| 50 |
reports, and Assignee: should reflect that. |
| 51 |
|
| 52 |
Maintaining a stable tree for an arch team means that someone on that |
| 53 |
team needs to do more than scratch their own itches - slacking should |
| 54 |
be fixed by relieving their burden, not pile on more, because that's |
| 55 |
precisely how volunteer work ultimately doesn't get done. |
| 56 |
|
| 57 |
|
| 58 |
jer |
Archives