Gentoo Archives: gentoo-dev

From: "Tiziano Müller" <dev-zero@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Re: About herds and their non-existant use
Date: Sat, 24 May 2008 10:26:59
Message-Id: g18qgo$pjd$1@ger.gmane.org
In Reply to: Re: [gentoo-dev] Re: About herds and their non-existant use by Marius Mauch
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

Replies

Subject Author
[gentoo-dev] Re: About herds and their non-existant use Ulrich Mueller <ulm@g.o>