Marius Mauch wrote:
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?)
Ahem, yes.
Consider these examples:
1) [EMAIL PROTECTED]
2) [EMAIL PROTECTED]
3) [EMAIL PROTECTED]
4) [EMAIL PROTECTED]
5) [EMAIL PROTECTED]
6) [EMAIL PROTECTED]
1) should validate to false because the alias actually is
[EMAIL PROTECTED] Can be validated against herds.xml
2) should validate to true. Can be validated against herds.xml
3) should validate to true. Needs validation against LDAP.
4) should validate to false. Needs validation against LDAP.
5) can't be validated and is therefore always true.
6) can't be validated and is therefore always true (but is in fact a typo)
Now you can say: ok, if we have @gentoo.org in it, we go through all the
cases and in case we don't find it in the LDAP or in herds.xml, it is a
faulty entry.
But that requires some more scripts and more time to parse than a
single xmllint-run.
Now: When we introduce a team (and maybe a dev) element in maintainer,
we exactly know, what it should be.
What the content of such elements should match (whether name or email in
herds.xml) is another question (where I tend to say it should be name
such that aliases can be changed in case of spam-issues, etc.).
- 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 ...?
XML 1.0 specification doesn't define an order and parsers can therefore
ignore it (using the data to auto-assign bugs can then be unreliable).
(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).
Changing your name because of technical difficulties? This is really not the
way to go. Systems have to be adjusted to meet our needs, not the other way
round (in case it is possible of course).
But nevertheless, it would be nice to have a common scheme as pointed out by
Flameeyes/Remi.
And I really, really, want to be able to create the project [EMAIL PROTECTED]
to
develop a client users can install to help us compile... ;-)
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.
Because it isn't possible to auto-assign bugs and because they weren't aware
that with a short script it is possible to resolve herd-names to
mail-aliases (well, probably they are but it slows down the workflow).
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.
The most likely candidate to be autogenerated or the most likely candidate
to autogenerate other information?
Well, as pointed out: it would be possible add a new element to herd
named watcher (or alike) which indicates a Dev not being part of the
team but wants to be added to the mail-alias. But then we really should
rename herd to team. The role-information is already in the herds.xml
so referencing the team-name from a project site should be enough to
generate the needed information (maybe extend the role-element by an
element to allow this: roleDeveloper/Security Liaison
