On Wed, 2006-06-14 at 17:04 -0400, Michael Cummings wrote:
> 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 [EMAIL PROTECTED] 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.

That's the thing.  That developer is wrong, and has done something
wrong.  I see nothing wrong with listing perl as the herd, *only* if
they have themselves as the maintainer.

> 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:

Not exactly...

Notice it says that a package is a member of a herd, not a person.  A
herd can have one or more projects responsible for maintaining the
packages in it.  In *most* cases, the group of developers responsible
for a given herd either have an alias that matches the herd, or are a
project with a similar alias.

> > 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.

That's where I disagree.  His practice is correct.  It should be
assigned to the maintainers of the herd, if no maintainer is listed, but
a herd is *not* a group of developers.  It is a group of packages, with
developers that maintain that group.

> 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.

Except that what I am saying is what the documentation says, and also
the intention of the documentation, as stated by some of the people who
wrote it, back when we had the whole "herds vs. teams" thread.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to