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

[Tom Wijsman]

On Tue, 30 Sep 2014 00:40:50 +0200
Jeroen Roovers <jer@g.o> wrote:

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

The outcome of what? Who agreed on it? If these questions have no
answers, the statements made have no meaning; they hide away the true
goal, which now becomes clear in "proposal to make bug tracker easier".

Then we arrive at the next question: What is so hard about bug tracking?

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

Knowing whether to contact one or more persons; eg., "/nick cjk" on
IRC can confuse this easily, where "!herd cjk" was as obvious as can be.

Note that the proposal involves trade-offs and consequences.

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

A comparison reveals that ordering gets introduced by this proposal:

Before: <maintainer> always goes _before_ <herd>
After:  <maintainer> goes _before or after_ the new herd <maintainer>

Therefore there was a lack of ordering; whereas the maintainer vs herd
order was implicit before, the proposal makes the order explicit.

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

The proposal is unaware of the amount of metadata.xml files; the extra
mapped lookup in herds.xml is free, changing metadata.xml files is not.

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

No, that[1]'s also about metadata.xml; furthermore, the proposal ignores
how the metadata.xml change will affect the meaning of a herd. Its
meaning is determined by its usage, which is affected by the proposal.

If you start using aliases instead, then what is there in a herd's name?

 [1]: http://www.gentoo.org/proj/en/metastructure/herds/#doc_chap4

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

Does it? Progress isn't stopped, we've been doing fine for ages; YAGNI.