| 1 |
On Wed, Sep 30, 2015 at 3:10 PM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
>>>>>> On Wed, 30 Sep 2015, Michał Górny wrote: |
| 3 |
> |
| 4 |
>> 2. We deprecate <herd/> in metadata.xml and assign herds/teams/projects |
| 5 |
>> via e-mail addresses. This keeps partial backwards compatibility with |
| 6 |
>> existing tools and solves the bug assignment issue. |
| 7 |
> |
| 8 |
> I'm pretty sure I've mentioned this before, but seems that you have |
| 9 |
> missed it. IMHO matching projects via their e-mail address is not a |
| 10 |
> good idea, because some projects have an address <project>-bugs@g.o or |
| 11 |
> dev-<project>@g.o which makes guessing the project's name (and finding |
| 12 |
> the project page) more difficult. Therefore, projects should be |
| 13 |
> matched by their proper name. |
| 14 |
> |
| 15 |
|
| 16 |
I kind-of prefer the email solution, because it reduces the number of |
| 17 |
identifiers people are effectively using. Bugzilla is tracking by |
| 18 |
email, herds by names, etc. |
| 19 |
|
| 20 |
If some projects/herds/whatevers have less-intuitive email aliases |
| 21 |
they can always create new ones that are easier to use. |
| 22 |
|
| 23 |
But, I don't feel very strongly about the issue. |
| 24 |
|
| 25 |
>> 2a. If someone really cares about this, we add an extra attribute or |
| 26 |
>> element which indicates the 'kind' of <maintainer/>. Otherwise, we just |
| 27 |
>> match herds.xml by e-mail address. |
| 28 |
> |
| 29 |
> Why don't we follow the KISS principle and replace <herd> by <project> |
| 30 |
> in metadata.xml? That is, create a project for every herd. |
| 31 |
> |
| 32 |
> Personally, I find this: |
| 33 |
> |
| 34 |
> <project>portage</project> |
| 35 |
> |
| 36 |
> easier to read than this: |
| 37 |
> |
| 38 |
> <maintainer type="project"> |
| 39 |
> <email>dev-portage@g.o<email> |
| 40 |
> </maintainer> |
| 41 |
|
| 42 |
Honestly, I think not specifying the type at all is simpler still. If |
| 43 |
you want to know what dev-portage@g.o is, then go to the single |
| 44 |
authoritative source herds.xml for alias->project/team/whatever |
| 45 |
mappings, rather than embedding this in every single package |
| 46 |
metadata.xml. |
| 47 |
|
| 48 |
I can be persuaded that one particular authoritative source is better |
| 49 |
than another, but I really don't like having multiple places that are |
| 50 |
all competing for the place you go to store the same information. |
| 51 |
|
| 52 |
-- |
| 53 |
Rich |
Archives