| 1 |
Kevin F. Quinn wrote: |
| 2 |
> Then you should not have committed it - as a dev it is your |
| 3 |
> responsibility to test any ebuilds your commit. There's nothing |
| 4 |
> stopping you doing the normal checks on the ebuild, even if you can't |
| 5 |
> read Hebrew. For example you should verify whether the '-j1' is really |
| 6 |
> necessary on emake. |
| 7 |
|
| 8 |
yeah, I do those tests of course. Had not thought of -j1 though. You are |
| 9 |
right - it is not needed. Sorry :( |
| 10 |
|
| 11 |
>> Furthermore I am actually part of |
| 12 |
>> maintainer-needed and commit fixes there. I am also on the |
| 13 |
>> maintainer-needed email alias. |
| 14 |
> |
| 15 |
> The point of a herd is to provide a contact for maintenance of the |
| 16 |
> member packages - and maintainer-needed by definition does not do |
| 17 |
> maintenance. |
| 18 |
|
| 19 |
yup. This is just so I can keep track of bugs filed against it while clearly |
| 20 |
separating them from bugs for packages which I judge more important and |
| 21 |
maintain directly. Support is provided by upstream and the user, |
| 22 |
build-testing/committing/ebuildfixes is provided by maintainer-needed |
| 23 |
(which is most likely me) |
| 24 |
|
| 25 |
>> Also maintainer-needed makes obvious to everyone that they do not |
| 26 |
>> have to ask me to fix sth. or take over the package -> less |
| 27 |
>> communication overhead. |
| 28 |
> |
| 29 |
> You can put notes into metadata.xml - see other instances for |
| 30 |
> examples; the easiest way is to have two maintainer entries, and in |
| 31 |
> the description field describe the maintenance arrangement. |
| 32 |
|
| 33 |
Give jeeves and herdstat support for reading notes and I might consider it. |
| 34 |
What annoys me most when putting myself in is that arch teams will ask me |
| 35 |
if I would want that stable. I honestly do not care. |
| 36 |
The annoying thing about it is that I get more than one bugmailspam about it |
| 37 |
and it also happens regularly for new versions :/ |
| 38 |
Such things the user should be able to decide himself. |
| 39 |
|
| 40 |
> Putting |
| 41 |
> "maintainer-needed" as the herd just means the package is essentially |
| 42 |
> unmaintained, and is a candidate for removal. |
| 43 |
|
| 44 |
that is what I want to imply by putting it in, you got me correctly. |
| 45 |
|
| 46 |
> We should not be putting |
| 47 |
> stuff into the official tree if no dev has taken responsibility for it. |
| 48 |
|
| 49 |
we are not putting new stuff in there, we are just fixing existing stuff so |
| 50 |
that it does not need to be removed. |
| 51 |
|
| 52 |
>> And for proxying it does not matter who is proxying. |
| 53 |
> |
| 54 |
> Proxying is more than just "doing whatever the non-dev says". By |
| 55 |
> committing to the tree, you take full responsibility for those |
| 56 |
> commits. |
| 57 |
|
| 58 |
I do. And if it breaks anyone I will fix it of course. |
| 59 |
|
| 60 |
> Whoever does the commit takes formal responsibility for those commits. |
| 61 |
> Therefore they should take note of bug activity relating to those |
| 62 |
> commits. If they don't care about that then they should not be acting |
| 63 |
> as proxy in that case. |
| 64 |
|
| 65 |
I do take note of all maintainer-needed bug activity. I do not put in myself |
| 66 |
to clearly separate those from the other bugs where I am directly |
| 67 |
maintaining stuff myself. |
| 68 |
|
| 69 |
> Surely this is what the Sunrise overlay was for; user-supplied ebuilds |
| 70 |
> that don't have a a Gentoo dev to take responsibility for maintenance. |
| 71 |
|
| 72 |
true. Sunrise is only for new ebuilds however. It is not designed as a place |
| 73 |
to dump ebuilds from portage to and force users of them to use Sunrise. |
| 74 |
If you or antarus or someone else wants to remove it from the tree feel free |
| 75 |
to do so, I am not in metadata, I do not care. I just fixed the bug. |
| 76 |
|
| 77 |
- Stefan |
| 78 |
|
| 79 |
-- |
| 80 |
gentoo-dev@g.o mailing list |
Archives