Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: Ulrich Mueller <ulm@g.o>
Cc: "Andreas K. Huettel" <dilfridge@g.o>, gentoo-project@l.g.o, Gentoo Council <council@g.o>
Subject: Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11
Date: Wed, 30 Sep 2015 19:47:48
Message-Id: 20150930214729.2fbc711b.mgorny@gentoo.org
In Reply to: Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2015-10-11 by Ulrich Mueller
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/>

Replies