herding (was: Re: [gentoo-dev] Re: A heretical thought? project sunrise as an almost-fork.)

[Michael Cummings]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OK, when I get invoked by name, then I have to respond :) (obligatory
bah) Mind you, this conversation really deserves its own thread since my
comments stray far, far away from the sunset project (that's going to be
my project for retired ebuilds available still in an overlay...hey, i
was making that up, but suddenly it sounds like a nice idea....)

Jakub Moc wrote:
> So, if they actually _are_
> maintained by the relevant herd, then you shouldn't dump stuff on that
> herd without discussing it w/ them first. I'm pretty sure mcummings will
> gladly explain to you what will happen if you do, as well as a bunch of
> other devs... :P

The gripe in this respect is that we have developers (who don't respond
to emails, friendly or otherwise) that will dump packages into dev-perl,
copy a metadata.xml from another pkg, and leave it as is - and since we
(perl project folks) use a stock metadata.xml listing perl as the herd,
and perl@g.o as maintainer, that means we get stuck with the
package. It sucks because you get bugs for badly written ebuilds and
your only trace of how it got there is either the ChangeLog (if you're
lucky) or the cvs log (had to resort to that once or twice too) - and in
the end, the bugger doesn't care who's package it is, they want it
fixed, and its not their fault for filing a bug, so you grind on and
take care of it.

Now getting all documented for a change, according to the Gentoo
Metadata page [1] every metadata file should contain at least one herd
subtag, and the maintenance of the package falls to that herd if there
is no maintainer also listed. (at least that's my interpretation of the
maintainer description, which says a package "[b]esides being a member
of a herd, can also be maintained directly." Even the examples in this
document direct the reader to believing that the herd listed is the
primary responsible party for the package, with the listed maintainer
being the alternate/additional maintainer. So when Jakub says:

> To make it pretty clear and explicit - bugs gets assigned to
> <maintainer> (if there's any in metadata.xml), and get CCed to <herd>
> (if there's any in metadata.xml). If there's no <maintainer>, whoever is
> in <herd> will get that bug assigned and can happily smack you <> once
> they've find out you've dumped the package on them without their
> knowledge...

he does appear to be correctly quoting the documentation on the site.
And we can't blame the bug wranglers for following this documentation -
we either update it or accept that that's what we have published to date.

's all I got. I may not be a lawyer - but I did ace my con law classes ;)

~mcummings

[1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkHnfq1ztTp5/Ti4RAi0dAJ44LTeKhabjIpxCi042KxRDwVgAjACglINH
4eUmZ8TqmrwEGNUnPsPV/mU=
=dWd0
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list