Re: [gentoo-dev] RFC: Deprecating and killing herds in metadata.xml

[Tom Wijsman]

On Mon, 29 Sep 2014 18:42:40 +0200
Jeroen Roovers <jer@g.o> wrote:

> On IRC we seem to have found some consensus about metadata.xml:

IRC is huge; where did you manage to find consensus in there with whom?

> 1 ) We should
> 1a) deprecate the <herd> tag in metadata.xml (that's 17,856 files or
>     so?) in favour of
> 1b) a conversion to their respective <maintainer> tags
> 1c) where the <email> tag serves the same purpose as <herd> but
>     bypasses herds.xml completely by just using the intended alias and
>     not the name of the herd (which some developers might want to keep
> in the <name> tag for whatever purpose).

This loses information that denotes it to be a herd, not a maintainer.

> 2 ) Important to note is that this makes the order in which tags in
>     metadata.xml are used in assigning bugs is made more explicit and
>     simple. Previously the first <maintainer> or in its absence the
>     first <herd> would be the Assignee, and the rest would be CC'd.
> This changes now to a much simpler scheme where
> 2a) the first <maintainer> is always the Assignee, and the rest is
>     CC'd, so that
> 2b) instances where metadata.xml lists a <maintainer> tag after a
>     <herd> tag would need to have the order fixed: the <herd> tags
> that are converted to <maintainer> tags should be moved to a place in
>     the file after the original first <maintainer> tag.

This loses the lack of ordering, requiring unnecessary attention to it.

> 3 ) We end up with metadata.xml files that have no <herd> tags and
> only <maintainer> tags.
> 3a) herds.xml is now unimportant in assigning bugs.
> 3b) Tools that use herds.xml no longer need a copy of herds.xml to
> look up who is responsible for a package.
> 3c) herds.xml can be safely kept up to date and used elsewhere and can
>     be safely phases out in time.

This is nice to have, as automatic assignments reveal; but this makes it
harder for a herd to change its e-mail address, which happens sometimes.

> 4 ) We might achieve the <herd> => <maintainer> conversion by
> 4a) setting up repoman to deny commits that keep <herd> or
> 4b) setting up repoman to automatically convert the entire thing
> 4c) both of which might end up taking a good while to complete, or
> 4d) do an automated mass conversion of the entire gentoo-x86 tree.

We might not need a conversion; it also changes/requires another tool.

> 5a) All ontological discussion of the meaning of herds and projects is
>     entirely unrelated - we're just looking to make it much easier to
> look
>     up metadata about packages using as few resources as possible.
> 5b) All ontological discussion of the meaning of herds and projects is
>     instantly rendered a lot less important. We have less need to
> bring this up every year or so.

That important ontological discussion is related as it is the origin,
the proposal changes a fundamental file of the Gentoo Herds Project[1];
by doing so, you make changes in the meaning of a herd and its context.

Reading further, we interestingly see that per the project page[1]

 1) the metadata in metadata.xml must have a <herd> tag present,
 2) a herd in herds.xml is not required to have an e-mail address;

where the latter (2) is even confirmed by the herds.xml DTD[2].

 [1]: http://www.gentoo.org/proj/en/metastructure/herds/
 [2]: http://www.gentoo.org/dtd/herds.dtd