| 1 |
Dnia 2015-09-16, o godz. 23:25:33 |
| 2 |
Michał Górny <mgorny@g.o> napisał(a): |
| 3 |
|
| 4 |
> So, what are your thoughts for unmessing this? |
| 5 |
|
| 6 |
For completeness, a semi-conservative idea that could be implemented |
| 7 |
relatively easily. |
| 8 |
|
| 9 |
1. Stop caring about names. If people want to call it a project, let it |
| 10 |
be a project. If people want to call it a herd, let it be a herd. |
| 11 |
Whatever. Let's assume all of them are some kind of teams. |
| 12 |
|
| 13 |
2. Provide a single machine-readable, developer-editable database of all |
| 14 |
teams. |
| 15 |
|
| 16 |
2a. All teams in the database are uniquely identified by their e-mail |
| 17 |
address. |
| 18 |
|
| 19 |
2b. The database can have some free-form fields for extra team info, |
| 20 |
like type (project, herd, whatever if you really care), human-readable |
| 21 |
name, description, homepage (-> wiki project page). |
| 22 |
|
| 23 |
2c. The database explicitly lists all team members, possibly with their |
| 24 |
role (lead/member). Optionally, we may allow listing sub-teams. |
| 25 |
|
| 26 |
2d. Project wiki pages should pull from this database. Otherwise, we |
| 27 |
consider the wiki project members lists useless and stop caring about |
| 28 |
them. |
| 29 |
|
| 30 |
3. Mail aliases correspond to all teams. We can implicitly append all |
| 31 |
team members to them but we also allow adding extra people interested |
| 32 |
in the bug mail there. Like we do right now. |
| 33 |
|
| 34 |
4. Only team members listed in the database are considered relevant to |
| 35 |
the package maintenance. Other mail alias members are considered |
| 36 |
spectators without any extra privileges. |
| 37 |
|
| 38 |
5. Package metadata lists e-mail addresses of all maintainers, either |
| 39 |
people or teams. |
| 40 |
|
| 41 |
5a. Each maintainer e-mail that is not a person must have a |
| 42 |
corresponding team database entry (and a mail alias, obviously). |
| 43 |
|
| 44 |
|
| 45 |
Now, for some practical least-effort implementation we can pretty much |
| 46 |
reuse the tools we have now (and gain in terms of compatibility). |
| 47 |
|
| 48 |
The team listing is pretty much what herds.xml is right now. We stop |
| 49 |
caring about <name/> and start using <email/> as the unique identifier. |
| 50 |
We make herds.xml obligatory and start using it as reference source for |
| 51 |
team listings. We may also add a <url/> element for project pages, |
| 52 |
and possibly <type/> to make some people who want fancy names happy. |
| 53 |
|
| 54 |
All other stuff is pretty much there already -- maintainer listings, |
| 55 |
with possibility of specifying roles, ability to subteam via |
| 56 |
<maintainersof/>. We also have an official webpage listing them [1]. |
| 57 |
We may possibly want to teach Wiki to get project members from |
| 58 |
herds.xml, dev.gentoo.org to update aliases from there and we need to |
| 59 |
teach willikins to use e-mail addresses instead of (or aside to) names. |
| 60 |
|
| 61 |
The package metadata.xml is pretty much ready too. We just stop using |
| 62 |
the stupid redundant <herd/> element, and put every herd as |
| 63 |
<maintainer/>. And again, we teach willikins to check maintainer e-mail |
| 64 |
addresses for herds.xml matches when doing !meta -v. |
| 65 |
|
| 66 |
So how do you feel about this? |
| 67 |
|
| 68 |
[1]:https://www.gentoo.org/inside-gentoo/developers/herds.html |
| 69 |
|
| 70 |
-- |
| 71 |
Best regards, |
| 72 |
Michał Górny |
| 73 |
<http://dev.gentoo.org/~mgorny/> |
Archives