On Tue, 30 Sep 2014 00:40:50 +0200 Jeroen Roovers <[email protected]> wrote:
> On Mon, 29 Sep 2014 23:16:32 +0200 > Tom Wijsman <[email protected]> wrote: > > > On Mon, 29 Sep 2014 18:42:40 +0200 > > Jeroen Roovers <[email protected]> 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.
