| 1 |
> Step 2 - Metadata.xml contains only a herd |
| 2 |
> ------------------------------------------ |
| 3 |
> 1. Take the herd element, and look up the herd in herds.xml to convert |
| 4 |
> to an email address. This email address must be a valid bugzilla |
| 5 |
> account. |
| 6 |
> 2. This email is treated as an implicit maintainer element after this |
| 7 |
> point. "<maintainer><email>${HERD_EMAIL}</email></maintainer>" |
| 8 |
> |
| 9 |
|
| 10 |
What about <herd>no-herd</herd>? Does that expand to |
| 11 |
<maintainer><email>maintainer-needed@g.o</email></maintainer>? |
| 12 |
Should it be added to herds.xml? |
| 13 |
|
| 14 |
I'd be all for the expansion. Consequently all ebuilds with metadata |
| 15 |
<herd>no-herd</herd> and |
| 16 |
<maintainer><email>maintainer-needed@g.o</email></maintainer> |
| 17 |
could be reduced to just <herd>no-herd</herd>... |
| 18 |
|
| 19 |
|
| 20 |
> Step 3 - <maintainer> element |
| 21 |
> ----------------------------- |
| 22 |
> 1. Add the maintainer element to an ordered list, in the order they are |
| 23 |
> present in the file. |
| 24 |
> 2. If an element appears more than once, the later element overrides |
| 25 |
> the earlier element. (This provides a route when the herd is assigned, |
| 26 |
> but does not wish to receive email for a specific package). 3. If a |
| 27 |
> maintainer element contains the 'ignoreauto=1' attribute AND a |
| 28 |
> non-empty role element (describing why this maintainer should not be |
| 29 |
> contacted), delete it from the list. |
| 30 |
|
| 31 |
What about <maintainer><email>maintainer-needed@g.o</email></maintainer>? |
| 32 |
And the case with no maintainer and <herd>no-herd</herd>? |
| 33 |
Those would be resolved by the <herd>no-herd</herd> expansion proposed |
| 34 |
above. |
| 35 |
|
| 36 |
> |
| 37 |
> Notes/Changes from before: |
| 38 |
> ==================================================== |
| 39 |
> - The herd element is always used. |
| 40 |
> - The 'contact' attribute is now called 'ignoreauto'. |
| 41 |
|
| 42 |
nice! |
| 43 |
|
| 44 |
> - The 'ignoreauto' is the logical opposite of the original 'contact' |
| 45 |
> attribute. |
| 46 |
> - The 'ignoreauto' attribute defaults to false. |
| 47 |
> - Any usage of the 'ignoreauto' attribute requires the role element to |
| 48 |
> be present. |
| 49 |
> - Herds that do not wish to be contacted for specific bugs should add a |
| 50 |
> maintainer element stating that (and use 'ignoreauto' on the |
| 51 |
> element). |
| 52 |
|
| 53 |
IMHO at least one herd should always be (at least) CC'ed (unless |
| 54 |
<herd>no-herd</herd> is the only herd) - in order to guarantee that a |
| 55 |
group is being notified about the problem. |
| 56 |
Or put differently: if an ebuild is part of a herd, but the herd doesn't |
| 57 |
want to know about it, why is ebuild part of the herd in the first place? |
| 58 |
|
| 59 |
> - Category level metadata.xml is now used for fallback if |
| 60 |
> this is a bug about a new package in an existing category. |
| 61 |
> - Category level metadata.xml may contain herd and maintainer elements. |
| 62 |
|
| 63 |
By allowing <maintainer> elements in category metadata we possibly create |
| 64 |
another (very weak) group maintainership. Is there a specific reason to |
| 65 |
allow more than <herd>? |
| 66 |
|
| 67 |
Thanks. |
| 68 |
Kind regards |
| 69 |
Thilo |
Archives