1 |
Marius Mauch wrote: |
2 |
> have the raw XML file. Anyway, that's maybe more of a policy problem, |
3 |
> we just need to enforce 'name == mail alias' (or would that be such a |
4 |
> horrible requirement?) |
5 |
Ahem, yes. |
6 |
|
7 |
Consider these examples: |
8 |
1) pgsql@g.o |
9 |
2) pgsql-bugs@g.o |
10 |
3) a.dev@g.o |
11 |
4) a.nonexisting.dev@g.o |
12 |
5) moon@×××.com |
13 |
6) pgsql-bugs@×××××.org |
14 |
|
15 |
1) should validate to false because the alias actually is |
16 |
pgsql-bugs@g.o. Can be validated against herds.xml |
17 |
2) should validate to true. Can be validated against herds.xml |
18 |
3) should validate to true. Needs validation against LDAP. |
19 |
4) should validate to false. Needs validation against LDAP. |
20 |
5) can't be validated and is therefore always true. |
21 |
6) can't be validated and is therefore always true (but is in fact a typo) |
22 |
|
23 |
Now you can say: ok, if we have "@gentoo.org" in it, we go through all the |
24 |
cases and in case we don't find it in the LDAP or in herds.xml, it is a |
25 |
faulty entry. |
26 |
But that requires some more scripts and more time to parse than a |
27 |
single "xmllint"-run. |
28 |
|
29 |
Now: When we introduce a <team> (and maybe a <dev>) element in <maintainer>, |
30 |
we exactly know, what it should be. |
31 |
What the content of such elements should match (whether <name> or <email> in |
32 |
herds.xml) is another question (where I tend to say it should be <name> |
33 |
such that aliases can be changed in case of spam-issues, etc.). |
34 |
|
35 |
> |
36 |
>> >> - it would simplify bug assignment rules, as the current case |
37 |
>> >> where a package has both a <herd> and a <maintainer> tag in |
38 |
>> >> metadata.xml no longer exists |
39 |
>> It doesn't. You can still have more than one <maintainer> in there. |
40 |
>> We'd have to introduce an attribute to mark the primary maintainer. |
41 |
> |
42 |
> Relying on the order of <maintainer> elements doesn't work because ...? |
43 |
XML 1.0 specification doesn't define an order and parsers can therefore |
44 |
ignore it (using the data to auto-assign bugs can then be unreliable). |
45 |
|
46 |
> (Assign to first listed maintainer, CC others) |
47 |
> |
48 |
>> >> - only have one location where members of a given team are listed, |
49 |
>> >> currently it's possible and quite likely that herds.xml and the |
50 |
>> >> mail alias files get out of sync |
51 |
>> Well, we need one location where the name of the team is mapped to the |
52 |
>> actual mail-alias. But I don't get what you're trying to say... |
53 |
> |
54 |
> Why do you need to separate the name from the alias? Sure, sometimes |
55 |
> there are technical reasons why you can't use your preferred name as |
56 |
> mail alias (when it matches a system account), but then you can just |
57 |
> adjust your name a bit (e.g. adding some suffix). |
58 |
Changing your name because of technical difficulties? This is really not the |
59 |
way to go. Systems have to be adjusted to meet our needs, not the other way |
60 |
round (in case it is possible of course). |
61 |
But nevertheless, it would be nice to have a common scheme as pointed out by |
62 |
Flameeyes/Remi. |
63 |
|
64 |
And I really, really, want to be able to create the project "gentoo@home" to |
65 |
develop a client users can install to help us compile... ;-) |
66 |
|
67 |
> Don't know if you're aware of this, but the separation of herd names |
68 |
> and aliases of the herd maintainers has always been something that |
69 |
> bug-wranglers complained about. |
70 |
Because it isn't possible to auto-assign bugs and because they weren't aware |
71 |
that with a short script it is possible to resolve herd-names to |
72 |
mail-aliases (well, probably they are but it slows down the workflow). |
73 |
|
74 |
> But my main issue is that currently we have multiple unconnected |
75 |
> locations where teams are defined, some more and some less important: |
76 |
> - herds.xml |
77 |
> - project pages |
78 |
> - mail aliases |
79 |
> - cvs access groups |
80 |
> - role definitions in ldap/roll-call |
81 |
> So when someone wants to change his roles there are a lot of places to |
82 |
> care about, and it's likely that one or more are forgotten and things |
83 |
> get out of sync, so you have different views of who actually belongs to |
84 |
> a group depending on what source you use. Don't know if it has improved |
85 |
> in the last years, but it used to happen quite often that herds.xml was |
86 |
> completely out of sync with reality simply because it didn't |
87 |
> really affect anything (now that jeeves is using it it's probably |
88 |
> become a bit better). |
89 |
> Ideally we could list that information in just one authorative |
90 |
> location, but that's not feasable for technical reasons, but if we can |
91 |
> eliminate one source (or auto-generate it from another source) the |
92 |
> problem is already reduced quite a bit. And herds.xml is IMO the most |
93 |
> likely candidates for that, but there are of course also other ways to |
94 |
> improve the situation. |
95 |
The most likely candidate to be autogenerated or the most likely candidate |
96 |
to autogenerate other information? |
97 |
|
98 |
Well, as pointed out: it would be possible add a new element to <herd> |
99 |
named "<watcher>" (or alike) which indicates a Dev not being part of the |
100 |
team but wants to be added to the mail-alias. But then we really should |
101 |
rename "herd" to "team". The role-information is already in the herds.xml |
102 |
so referencing the team-name from a project site should be enough to |
103 |
generate the needed information (maybe extend the role-element by an |
104 |
element to allow this: <role>Developer/Security Liaison |
105 |
<description>emacs</description></role>). |
106 |
|
107 |
And why do we reference the project-url in <maintainingproject> and not just |
108 |
the name of the project? |
109 |
|
110 |
Cheers, |
111 |
Tiziano |
112 |
|
113 |
|
114 |
-- |
115 |
gentoo-dev@l.g.o mailing list |