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) pgsql@g.o
2) pgsql-bugs@g.o
3) a.dev@g.o
4) a.nonexisting.dev@g.o
5) moon@...
6) pgsql-bugs@...

1) should validate to false because the alias actually is
pgsql-bugs@g.o. 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 "gentoo@home" 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: <role>Developer/Security Liaison
<description>emacs</description></role>).

And why do we reference the project-url in <maintainingproject> and not just
the name of the project?

Cheers,
Tiziano


-- 
gentoo-dev@g.o mailing list