1 |
Dnia 2015-09-30, o godz. 21:39:11 |
2 |
Ulrich Mueller <ulm@g.o> napisał(a): |
3 |
|
4 |
> >>>>> On Wed, 30 Sep 2015, Michał Górny wrote: |
5 |
> |
6 |
> >> I'm pretty sure I've mentioned this before, but seems that you have |
7 |
> >> missed it. IMHO matching projects via their e-mail address is not a |
8 |
> >> good idea, because some projects have an address <project>-bugs@g.o |
9 |
> >> or dev-<project>@g.o which makes guessing the project's name (and |
10 |
> >> finding the project page) more difficult. Therefore, projects |
11 |
> >> should be matched by their proper name. |
12 |
> |
13 |
> > And why would you need to guess that? Wiki project names are already |
14 |
> > disjoint from herds.xml <name/>s, so I don't see a problem with |
15 |
> > that. |
16 |
> |
17 |
> We would need a "shortname" or "id" field in the project page |
18 |
> template, e.g. "Quality Assurance" -> "qa" (but I guess most would be |
19 |
> trivial, like "Emacs" -> "emacs"). I've already discussed this with |
20 |
> a3li some time ago, and there should be no technical problems. |
21 |
|
22 |
And what's the technical problem of using e-mail address instead |
23 |
which is already there and is a valid global identifier? Why do we have |
24 |
to duplicate more information when we can use something we need there |
25 |
anyway? |
26 |
|
27 |
> |
28 |
> >> > 2a. If someone really cares about this, we add an extra attribute or |
29 |
> >> > element which indicates the 'kind' of <maintainer/>. Otherwise, we just |
30 |
> >> > match herds.xml by e-mail address. |
31 |
> >> |
32 |
> |
33 |
> >> Why don't we follow the KISS principle and replace <herd> by <project> |
34 |
> >> in metadata.xml? That is, create a project for every herd. |
35 |
> |
36 |
> > Because this: |
37 |
> |
38 |
> > 1. breaks backwards compatibility, |
39 |
> |
40 |
> It is already broken. For example, <maintainingproject> in herds.xml |
41 |
> does no longer work. |
42 |
|
43 |
Small breakage is no excuse for bigger breakage. Right now, all package |
44 |
managers still work. Tools like 'equery m' still get the e-mails for |
45 |
bug assignments right. |
46 |
|
47 |
With your solution, they all broke immediately. 'equery m' no longer |
48 |
lists correct maintainers. All package managers need to be updated, |
49 |
including *API changes*. |
50 |
|
51 |
> > 2. doesn't change anything but the name which is the most meaningless, |
52 |
> > waste-of-time change you could have proposed. if you do this, please |
53 |
> > count me out. |
54 |
> |
55 |
> Huh? You really think that getting rid of herds and having all |
56 |
> information about project membership in one central place (namely, |
57 |
> the project page in the wiki) doesn't change anything? |
58 |
|
59 |
Excuse me, but what are you talking about now? All you said was to |
60 |
change the tag, you didn't mention anything about wiki. |
61 |
|
62 |
And if you really want to keep this information in the Wiki, then I'm |
63 |
strongly against it. Because I really like having metadata is useful |
64 |
format in git repo rather than some proprietary database which can't |
65 |
even list all developers properly and require fancy software to access. |
66 |
|
67 |
-- |
68 |
Best regards, |
69 |
Michał Górny |
70 |
<http://dev.gentoo.org/~mgorny/> |