Kevin F. Quinn wrote: > Then you should not have committed it - as a dev it is your > responsibility to test any ebuilds your commit. There's nothing > stopping you doing the normal checks on the ebuild, even if you can't > read Hebrew. For example you should verify whether the '-j1' is really > necessary on emake.
yeah, I do those tests of course. Had not thought of -j1 though. You are right - it is not needed. Sorry :( >> Furthermore I am actually part of >> maintainer-needed and commit fixes there. I am also on the >> maintainer-needed email alias. > > The point of a herd is to provide a contact for maintenance of the > member packages - and maintainer-needed by definition does not do > maintenance. yup. This is just so I can keep track of bugs filed against it while clearly separating them from bugs for packages which I judge more important and maintain directly. Support is provided by upstream and the user, build-testing/committing/ebuildfixes is provided by maintainer-needed (which is most likely me) >> Also maintainer-needed makes obvious to everyone that they do not >> have to ask me to fix sth. or take over the package -> less >> communication overhead. > > You can put notes into metadata.xml - see other instances for > examples; the easiest way is to have two maintainer entries, and in > the description field describe the maintenance arrangement. Give jeeves and herdstat support for reading notes and I might consider it. What annoys me most when putting myself in is that arch teams will ask me if I would want that stable. I honestly do not care. The annoying thing about it is that I get more than one bugmailspam about it and it also happens regularly for new versions :/ Such things the user should be able to decide himself. > Putting > "maintainer-needed" as the herd just means the package is essentially > unmaintained, and is a candidate for removal. that is what I want to imply by putting it in, you got me correctly. > We should not be putting > stuff into the official tree if no dev has taken responsibility for it. we are not putting new stuff in there, we are just fixing existing stuff so that it does not need to be removed. >> And for proxying it does not matter who is proxying. > > Proxying is more than just "doing whatever the non-dev says". By > committing to the tree, you take full responsibility for those > commits. I do. And if it breaks anyone I will fix it of course. > Whoever does the commit takes formal responsibility for those commits. > Therefore they should take note of bug activity relating to those > commits. If they don't care about that then they should not be acting > as proxy in that case. I do take note of all maintainer-needed bug activity. I do not put in myself to clearly separate those from the other bugs where I am directly maintaining stuff myself. > Surely this is what the Sunrise overlay was for; user-supplied ebuilds > that don't have a a Gentoo dev to take responsibility for maintenance. true. Sunrise is only for new ebuilds however. It is not designed as a place to dump ebuilds from portage to and force users of them to use Sunrise. If you or antarus or someone else wants to remove it from the tree feel free to do so, I am not in metadata, I do not care. I just fixed the bug. - Stefan -- gentoo-dev@gentoo.org mailing list
