| 1 |
On Sun, 03 Sep 2006 13:57:10 +0200 |
| 2 |
Stefan Schweizer <genstef@g.o> wrote: |
| 3 |
|
| 4 |
> Kevin F. Quinn wrote: |
| 5 |
> > I don't think it's a good idea for devs to be putting stuff into the |
| 6 |
> > tree without taking responsibility for it. |
| 7 |
> sure I can put myself in there but it will help no one because I |
| 8 |
> cannot test the thing. |
| 9 |
|
| 10 |
Then you should not have committed it - as a dev it is your |
| 11 |
responsibility to test any ebuilds your commit. There's nothing |
| 12 |
stopping you doing the normal checks on the ebuild, even if you can't |
| 13 |
read Hebrew. For example you should verify whether the '-j1' is really |
| 14 |
necessary on emake. |
| 15 |
|
| 16 |
> Furthermore I am actually part of |
| 17 |
> maintainer-needed and commit fixes there. I am also on the |
| 18 |
> maintainer-needed email alias. |
| 19 |
|
| 20 |
For a start, "maintainer-needed" is just a mail alias, it is not a |
| 21 |
herd and never can be, by definition. See |
| 22 |
http://www.gentoo.org/proj/en/metastructure/herds/herds.xml. |
| 23 |
|
| 24 |
The point of a herd is to provide a contact for maintenance of the |
| 25 |
member packages - and maintainer-needed by definition does not do |
| 26 |
maintenance. |
| 27 |
|
| 28 |
> Also maintainer-needed makes obvious to everyone that they do not |
| 29 |
> have to ask me to fix sth. or take over the package -> less |
| 30 |
> communication overhead. |
| 31 |
|
| 32 |
You can put notes into metadata.xml - see other instances for |
| 33 |
examples; the easiest way is to have two maintainer entries, and in |
| 34 |
the description field describe the maintenance arrangement. Putting |
| 35 |
"maintainer-needed" as the herd just means the package is essentially |
| 36 |
unmaintained, and is a candidate for removal. We should not be putting |
| 37 |
stuff into the official tree if no dev has taken responsibility for it. |
| 38 |
|
| 39 |
> > I would expect that either |
| 40 |
> > the herd is set appropriately (which means either the committer be a |
| 41 |
> > member of the herd, or the herd explicitly agree to be proxy), |
| 42 |
> which is the case here. |
| 43 |
|
| 44 |
See above - maintainer-needed does not satisfy the requirements of the |
| 45 |
herd entry. |
| 46 |
|
| 47 |
> > or the |
| 48 |
> > committer be listed as a maintainer email address along with |
| 49 |
> > whoever is being proxied. |
| 50 |
> the committer in this case has no interest in maintaining the thing. |
| 51 |
|
| 52 |
Even more reason the package should acquire a dev to maintain it, or be |
| 53 |
removed from the tree. |
| 54 |
|
| 55 |
> And for proxying it does not matter who is proxying. |
| 56 |
|
| 57 |
Proxying is more than just "doing whatever the non-dev says". By |
| 58 |
committing to the tree, you take full responsibility for those |
| 59 |
commits. |
| 60 |
|
| 61 |
> > Further I believe bugs against such packages should be |
| 62 |
> > assigned to the @gentoo.org address (proxy maintainer if there is |
| 63 |
> > one, herd otherwise), and CC'ed to the proxied maintainer address. |
| 64 |
> |
| 65 |
> this does not allow the actual maintainer to close the bug and causes |
| 66 |
> a lot of bugspam for a person who does not care about it and should |
| 67 |
> be only contacted in the end to commit fixes/patches/bumps. |
| 68 |
|
| 69 |
Whoever does the commit takes formal responsibility for those commits. |
| 70 |
Therefore they should take note of bug activity relating to those |
| 71 |
commits. If they don't care about that then they should not be acting |
| 72 |
as proxy in that case. |
| 73 |
|
| 74 |
|
| 75 |
Surely this is what the Sunrise overlay was for; user-supplied ebuilds |
| 76 |
that don't have a a Gentoo dev to take responsibility for maintenance. |
| 77 |
|
| 78 |
-- |
| 79 |
Kevin F. Quinn |
Archives