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

[Jeroen Roovers]

On Mon, 29 Sep 2014 23:16:32 +0200
Tom Wijsman <TomWij@g.o> wrote:

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

I have no idea how to respond to that. It doesn't matter whether you
were there or not: this was the outcome we agreed on and here is a
proposal that should make working with the bug tracker a lot easier.

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

<maintainer>
  <email>[address of the herd]</email>
  <name>[name of the herd]</name> <!-- if you like -->
</maintainer>

Please provide some examples of when and how that piece of information,
"herd", is important.

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

There has never been a lack of ordering. The way bugs are assigned
since 2008 is as described in 2a. It requires not reordering the XML
tags. 2b says the order of appearance denotes the Assignee.

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

Go back in history and tell us how often herds change their e-mail
address. And how many metadata.xml files would have been affected. And
how that reflects on the future. And then compare that with the everday
chore of doing the extra lookup in herds.xml that shouldn't be needed
at all if the only thing you need is an e-mail address.

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

The proposal says we convert <herd> to <maintainer> in metadata.xml.

4d explains how you wouldn't need changes to repoman.

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

No, that's about changing herds.xml. This is about changing
metadata.xml. You can keep the herd information in herds.xml and make
metadata.xml a lot more easy to handle at the same time.

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

Maybe that should be fixed, then (including outdated information and
factual errors). I don't see how it would stop progress. It just needs
some minor rethinking.


     jer