| 1 |
On 09/16/2015 04:25 PM, Michał Górny wrote: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
> Right now we kinda have three layers of team package maintainership |
| 5 |
> in Gentoo: |
| 6 |
> |
| 7 |
> 1. e-mail aliases + bugzilla accounts, |
| 8 |
> |
| 9 |
> 2. herds, |
| 10 |
> |
| 11 |
> 3. projects. |
| 12 |
> |
| 13 |
> Now if we get into the details, it's all very messy. |
| 14 |
> |
| 15 |
> |
| 16 |
> E-mail aliases are pretty much handled by obscure, proprietary |
| 17 |
> scripts. Formally Gentoo developers can read and modify them, but |
| 18 |
> willikins also provides read access to most of the aliases. E-mail |
| 19 |
> aliases specify the de-facto list of people receiving bug mail |
| 20 |
> and other package inquiries. E-mail aliases are either listed directly |
| 21 |
> as <maintainer/> objects, or indirectly provided through herds. |
| 22 |
> |
| 23 |
> It should be noted that Bugzilla allows users to 'watch' particular |
| 24 |
> e-mail addresses, effectively subscribing users to the bug mail. This |
| 25 |
> can extend the list of people receiving bug mail for a package. |
| 26 |
> |
| 27 |
> Herds are stored in data/api.git repository, as an .xml file. |
| 28 |
> Additionally, read access is provided through api.gentoo.org site. |
| 29 |
> Herds specify explicitly the de-facto maintainers of packages maintained |
| 30 |
> by herds. In the past they could alternatively refer to project pages |
| 31 |
> but that support was dropped along with project wiki migration. Herds |
| 32 |
> are also mapped to e-mail aliases (which may list different people). |
| 33 |
> Herds are listed as <herd> objects. |
| 34 |
> |
| 35 |
> Projects are stored in the proprietary databases of our Wiki instance. |
| 36 |
> Projects may specify maintainers of packages where herd is supposed to |
| 37 |
> map directly to a project (though herds.xml doesn't provide a correct |
| 38 |
> mapping anymore), and also when the particular project's e-mail address |
| 39 |
> is listed as maintainer. Projects are usually (though not obligatorily) |
| 40 |
> mapped to e-mail aliases. There is no explicit listing for projects in |
| 41 |
> metadata.xml. |
| 42 |
> |
| 43 |
> |
| 44 |
> To summarize, I see the following issues: |
| 45 |
> |
| 46 |
> 1. All three layers are totally disjoint, stored in completely |
| 47 |
> different format in completely different places. |
| 48 |
> |
| 49 |
> 2. Only herds and aliases can be cleanly mapped via metadata.xml. |
| 50 |
> |
| 51 |
> 3. If an alias is given as maintainer, and the alias maps both to |
| 52 |
> a herd and a project, it is unclear which of the two it is. |
| 53 |
> |
| 54 |
> 4. Herds can no longer refer to projects, so all project members are |
| 55 |
> duplicated in herds (= increased maintenance burden). |
| 56 |
> |
| 57 |
> 5. Projects can't list members who do not have Wiki accounts or are |
| 58 |
> not Gentoo developers. |
| 59 |
> |
| 60 |
> So, what are your thoughts for unmessing this? |
| 61 |
> |
| 62 |
|
| 63 |
Herds are groups of developers that can then be mapped to a package. |
| 64 |
|
| 65 |
Aliases are groups of developers and/or others that can be mapped to a |
| 66 |
package (and more, but at least that). |
| 67 |
|
| 68 |
Is there a reason not to do a merge into it all being one or the other |
| 69 |
(preferably aliases I think, as it's somewhat more explicit with mail). |
| 70 |
-- |
| 71 |
Matthew Thode (prometheanfire) |
Archives