1 |
On Sat, 10 Jun 2006 10:27:29 -0400 |
2 |
Chris Gianelloni <wolf31o2@g.o> wrote: |
3 |
|
4 |
[lots of good stuff - +lots Chris] |
5 |
|
6 |
> Not so many moons ago, new ebuilds were submitted to bugzilla. The |
7 |
> bug wranglers would assign the bugs to the team most likely to end up |
8 |
> as the maintainers, and new ebuilds either made it into the tree, or |
9 |
> sat in bugzilla until the interest was there for it to be added, if |
10 |
> ever. Some people felt that this process left lots of packages in |
11 |
> bugzilla, with no one to watch over them. Because of this, the |
12 |
> maintainer-wanted, and maintainer-needed bugzilla accounts were |
13 |
> created to assist in tracking these bugs/packages. This was a good |
14 |
> idea at the time, and worked fairly well so long as there were |
15 |
> developers going through and actively searching for bugs, that were |
16 |
> no longer assigned to the relevant teams, but instead, assigned into |
17 |
> some big dumping ground for new package requests. |
18 |
|
19 |
I think it's clear that the maintainer-wanted/maintainer-needed hasn't |
20 |
actually solved the problem it was trying to address. While it has |
21 |
improved on some counts, I think the fact that herd maintainers |
22 |
are not watching those aliases means that new builds are not being |
23 |
brought to the attention of the devs most likely to take them on. |
24 |
|
25 |
Instead of having sunrise on gentoo.org, which I agree with Chris is |
26 |
fundamentally a bad idea, could we simply go back to assigning new |
27 |
builds to the most relevant herd alias, but also add |
28 |
maintainer-wanted/needed to the CC:? That way some responsibility is |
29 |
assigned to the herd to deal with it one way or another. If the |
30 |
herd does not have the manpower to deal with it they can just reassign |
31 |
to maintainer-needed and CC the herd, indicating they need someone |
32 |
to join the group of herd maintainers to take the package on. With |
33 |
maintainer-* on CC the benefits accrued so far from having a bunch of |
34 |
people helping to iron out early QA problems would remain, and at the |
35 |
same time the group of people most likely to pick up the package would |
36 |
also be aware of it. |
37 |
|
38 |
-- |
39 |
Kevin F. Quinn |