> Step 2 - Metadata.xml contains only a herd
> ------------------------------------------
> 1. Take the herd element, and look up the herd in herds.xml to convert
> to an email address. This email address must be a valid bugzilla
> account.
> 2. This email is treated as an implicit maintainer element after this
> point. "<maintainer><email>${HERD_EMAIL}</email></maintainer>"
>What about <herd>no-herd</herd>? Does that expand to <maintainer><email>[EMAIL PROTECTED]</email></maintainer>? Should it be added to herds.xml? I'd be all for the expansion. Consequently all ebuilds with metadata <herd>no-herd</herd> and <maintainer><email>[EMAIL PROTECTED]</email></maintainer> could be reduced to just <herd>no-herd</herd>... > Step 3 - <maintainer> element > ----------------------------- > 1. Add the maintainer element to an ordered list, in the order they are > present in the file. > 2. If an element appears more than once, the later element overrides > the earlier element. (This provides a route when the herd is assigned, > but does not wish to receive email for a specific package). 3. If a > maintainer element contains the 'ignoreauto=1' attribute AND a > non-empty role element (describing why this maintainer should not be > contacted), delete it from the list. What about <maintainer><email>[EMAIL PROTECTED]</email></maintainer>? And the case with no maintainer and <herd>no-herd</herd>? Those would be resolved by the <herd>no-herd</herd> expansion proposed above. > > Notes/Changes from before: > ==================================================== > - The herd element is always used. > - The 'contact' attribute is now called 'ignoreauto'. nice! > - The 'ignoreauto' is the logical opposite of the original 'contact' > attribute. > - The 'ignoreauto' attribute defaults to false. > - Any usage of the 'ignoreauto' attribute requires the role element to > be present. > - Herds that do not wish to be contacted for specific bugs should add a > maintainer element stating that (and use 'ignoreauto' on the > element). IMHO at least one herd should always be (at least) CC'ed (unless <herd>no-herd</herd> is the only herd) - in order to guarantee that a group is being notified about the problem. Or put differently: if an ebuild is part of a herd, but the herd doesn't want to know about it, why is ebuild part of the herd in the first place? > - Category level metadata.xml is now used for fallback if > this is a bug about a new package in an existing category. > - Category level metadata.xml may contain herd and maintainer elements. By allowing <maintainer> elements in category metadata we possibly create another (very weak) group maintainership. Is there a specific reason to allow more than <herd>? Thanks. Kind regards Thilo
pgpxulkMsBDop.pgp
Description: PGP signature
