On Thu, 22 May 2008 08:05:07 +0200 Tiziano Müller <[EMAIL PROTECTED]> 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@lists.gentoo.org mailing list
