1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
\summary{2015}{10}{25}
\agendaitem{Projects, herds, etc.}
\index{herds}\index{projects!identification}\index{metadata.xml}
References:
\begin{itemize}
\item
\agoref{gentoo-project}{179d5d298333dfeef45a6eb78f0d6f17}
\item
\agoref{gentoo-project}{70451197c3109e61ddd27e14a7bf89fa}
\item
\agoref{gentoo-project}{3cf270a336636b94187b2a2b8f1b7e7f}
\item
\agoref{gentoo-project}{f595f9fef4bce02c875e980ec5d21841}
\end{itemize}
A lengthy discussion on the merits of deprecating herds and on how to
precisely do that resulted. The suggestion to use GUIDs for project
identification was dismissed as slightly impractical, even though they
provide for a near-unlimited number of projects.
\vote{A: The concept of "herds" is abandoned, and the usage of the term
deprecated. As a replacement, a package may be maintained by a
project.}{
7 yes, unanimous}
\vote{B: do we want
\begin{enumerate}[label=\alph*)]
\item "$<$project$>$bla$<$/project$>$" or
\item "$<$maintainer$><$project$>$bla$<$/project$><$/maintainer$>$" or
\item "$<$maintainer type="project"$>$bla$<$/maintainer$>$" or
\item "$<$maintainer$><$email$>$bla@gentoo.org$<$/email$><$/maintainer$>$" ?
\end{enumerate}
}{
3x a, 2x c, 2x d}
This led to a discussion on the meaning of the vote outcome, and it
was decided to re-formulate the question into several votes.
\vote{C: New $<$project$>$ tag, or add something to existing $<$maintainer$>$
tag?}{
4x project and 3x maintainer}
\vote{D: what goes into the $<$project$>$ tag? a project shortname or an
e-mail address?}{
4x shortname, 1x e-mail, 2x abstain}
\vote{E: do we want a 1:1 mapping of a new e-mail address to the
project shortname?}{
4 yes, 2 no}
\vote{F: define the project shortname on the wiki project page, and
expect that any project is *also* reachable as
shortname@proj.gentoo.org}{
4 yes, 2 abstain}
After these decisions several council members stated that things were
going the wrong way and that they would like to change their votes for
earlier decisions, thereby making latter decisions obsolete. As a
consequence, it was suggested to scrap the just-made decisions again
and request a GLEP on the issue.
\vote{All votes today from vote B on are anulled. The council recommends
that the details on herds to projects transition should be worked out
in a GLEP.}{
6 yes, 1 abstain}
\agendaitem{Open bugs with council participation}
\bug{503382}: Ulm stated that the 20131210 summary has been written and submitted,
and minor corrections were suggested.
\agendaitem{Open floor}
No issues were brought up.
|
GitWeb