Re: [gentoo-dev] Re: About herds and their non-existant use

[Marius Mauch]

On Thu, 22 May 2008 08:05:07 +0200
Tiziano Müller <dev-zero@g.o> wrote:

> While I think the herds concecpt is somewhat useless, I'd rather like
> to see something like this instead:
>
> <maintainer>
>   <team>foobar</team>
> </maintainer>
>
> This makes it clear that it is a team instead of a person (where
> <name> would have been used)
>
> And the herds.xml isn't completely useless, but I'd rather name it
> teams.xml and list the teams there. This way we can validated the
> team mentioned in <team>...</team> against the list of available
> teams and make sure the complete thing is valid (can be done in the
> current metadata.dtd or in a future metadata.xsd).
> (If we're gonna re-use the <email>...</email> element for the
> herd-alias, we can never validate it. And I'm personally for the: "if
> something can be automatically validated, it should be")

Hmm, in that case maybe it's be possible to use a similar system for
devs, e.g. 
<maintainer>
  <dev>genone</dev>
</maintainer>
and only use the <email> element for non-dev maintainers and upstream
contacts. Anyway, as long as we use the same tag to list both
individual and group maintainers it would be an improvement IMO.

> >> This would have a number of benefits:
> >> - you no longer have to look at herds.xml to determine the actual
> >> maintainers of a given package (as herd-name and associated mail
> >> alias don't always match)
> I don't consider this much of a problem. You just have to know
> xsl/xpath to cope with this as generating the list of mail-aliases to
> assign this bug to is a simple xsl-transformation...
> When we use XML we can also use the right tools to handle them, can't
> we?

My point is that it's an unneccessary extra step Sometimes you only
have the raw XML file. Anyway, that's maybe more of a policy problem,
we just need to enforce 'name == mail alias' (or would that be such a
horrible requirement?)

> >> - it would simplify bug assignment rules, as the current case
> >> where a package has both a <herd> and a <maintainer> tag in
> >> metadata.xml no longer exists
> It doesn't. You can still have more than one <maintainer> in there.
> We'd have to introduce an attribute to mark the primary maintainer.

Relying on the order of <maintainer> elements doesn't work because ...?
(Assign to first listed maintainer, CC others)

> >> - only have one location where members of a given team are listed,
> >> currently it's possible and quite likely that herds.xml and the
> >> mail alias files get out of sync
> Well, we need one location where the name of the team is mapped to the
> actual mail-alias. But I don't get what you're trying to say...

Why do you need to separate the name from the alias? Sure, sometimes
there are technical reasons why you can't use your preferred name as
mail alias (when it matches a system account), but then you can just
adjust your name a bit (e.g. adding some suffix).
Don't know if you're aware of this, but the separation of herd names
and aliases of the herd maintainers has always been something that
bug-wranglers complained about.
But my main issue is that currently we have multiple unconnected
locations where teams are defined, some more and some less important:
- herds.xml
- project pages
- mail aliases
- cvs access groups
- role definitions in ldap/roll-call
So when someone wants to change his roles there are a lot of places to
care about, and it's likely that one or more are forgotten and things
get out of sync, so you have different views of who actually belongs to
a group depending on what source you use. Don't know if it has improved
in the last years, but it used to happen quite often that herds.xml was
completely out of sync with reality simply because it didn't
really affect anything (now that jeeves is using it it's probably
become a bit better).
Ideally we could list that information in just one authorative
location, but that's not feasable for technical reasons, but if we can
eliminate one source (or auto-generate it from another source) the
problem is already reduced quite a bit. And herds.xml is IMO the most
likely candidates for that, but there are of course also other ways to
improve the situation.

Marius
-- 
gentoo-dev@l.g.o mailing list