| 1 |
Markus Nigbur wrote: |
| 2 |
> Assigning to m-n@g.o and adding the actual fitting herd to CC is the most |
| 3 |
> elegant option, IMHO. |
| 4 |
> However we do it, we should really agree on one solution, to get more |
| 5 |
> structure into the chaos. |
| 6 |
|
| 7 |
Here's what I'd propose: |
| 8 |
|
| 9 |
This only applies to new packages, as opposed to version bumps or whatever else: |
| 10 |
|
| 11 |
When an ebuild or ebuild request is posted to bugzilla, the bug wranglers |
| 12 |
attempt to find an appropriate herd or developer to assign it to, and the |
| 13 |
ebuild is keyworded with EBUILD or REQUEST depending whether an ebuild was |
| 14 |
included or not. |
| 15 |
|
| 16 |
If the herd or developer does not want to maintain the package and they feel |
| 17 |
that there is another herd or developer where this package would be more |
| 18 |
appropriately maintained, then they should reassign it to them. |
| 19 |
|
| 20 |
At any point, if a developer or herd decides that they do not want to maintain |
| 21 |
the package at the current time, and there is no more appropriate |
| 22 |
herd/developer, then they reassign it to maintainer-needed@g.o putting |
| 23 |
the most appropriate herd(s)/developer(s) on CC. |
| 24 |
|
| 25 |
Interested developers can then take bugs from the maintainer-needed alias and |
| 26 |
reassign to themselves before getting the ebuild included in portage - but the |
| 27 |
usual policies still apply, for example if its a web application you'll |
| 28 |
probably be asked to join the webapps herd, and if its a kernel then you'll |
| 29 |
have to go through the torture chamber and then join our project before adding |
| 30 |
the package, etc... |
| 31 |
|
| 32 |
Herds/developers that are CC'd on the maintainer-needed bugs are free to |
| 33 |
completely close the bugs if there is a good reason why the package won't be |
| 34 |
included in portage at the current time. For example, I'd reject an ebuild for |
| 35 |
an external 2.6 kernel module which doesn't work for kernels 2.6.4 and newer, |
| 36 |
because we don't support those older kernels at all. (These kind of bugs might |
| 37 |
even be closed before it got assigned to maintainer-needed) |
| 38 |
|
| 39 |
Developers can query for open maintainer-needed EBUILD bugs if they are |
| 40 |
looking for new packages to maintain, and users can query for open |
| 41 |
maintainer-needed REQUEST bugs if they want some ebuild writing practice. |
| 42 |
|
| 43 |
Perhaps a complete list of open maintainer-needed bugs could be added to the |
| 44 |
default preset queries..? |
| 45 |
|
| 46 |
|
| 47 |
Any comments on that? |
| 48 |
|
| 49 |
|
| 50 |
> - Developer Handbook (which really needs a section about how bugs are treated. |
| 51 |
> I always wanted to write up a draft when I find the time...) |
| 52 |
|
| 53 |
I think we need some real bugzilla documentation that covers both basic usage |
| 54 |
and also policies on bugs/resolutions/ownership and what to do if you think |
| 55 |
your bug is being ignored. This is also on my todo list but has been for a |
| 56 |
long time. |
| 57 |
|
| 58 |
Daniel |
| 59 |
-- |
| 60 |
gentoo-dev@g.o mailing list |
Archives