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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
\summary{2008}{1}{10}
Agenda call: \agoref{gentoo-dev}{6a77b647228fc497a720151fa8a6e54c}
\agendaitem{GLEP 54: scm package version suffix}
Reference: \glep{54}
The proposed GLEP was discussed. Comments from portage maintainer \dev{genone}
were:
\begin{itemize}
\item
There is no statement about compatibility/implementation plans in the GLEP.
\item
While a distinction between CPV and atom may not be technically required, it
might be useful to have
\item
(minor) If the version part is optional there could be some complications.
\end{itemize}
So is this something we'd like to have (before we decide on details)? The -9999
version usage in the tree was started since there was no progress on \bug{9202}.
Other (implementation) ideas that came up during discussion:
\begin{itemize}
\item
Should we use a -scm or _scm suffix?
\item
Alternatively, handling (-$\vert$_pre)9999) as scm versions per definition?
\item
Implement this as dynamic package sets?
\end{itemize}
The topic was pushed back to the gentoo-dev mailing list as there are too many
unresolved questions at the moment. \dev{peper} is given the task to repost it
and expand on usefulness / use cases as well as on compatibility issues.
\agendaitem{GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)}
Reference: \glep{55}
This resulted in a lengthy discussion on technical advantages and
disadvantages, including using a pre-sourcing EAPI as mask before providing the
final EAPI of an ebuild via sourcing, or converting the EAPI assignment to a
function call and using a repository bashrc for backwards
compatibility.\footnote{The whole proposal was
initially kicked off for allowing eclasses to use a different EAPI from an
ebuild.} There was agreement that EAPI subdirectories are not feasible.
The topic was pushed back to the gentoo-dev mailing list as there are too many
unresolved questions at the moment.
\agendaitem{Slacker arches}
\index{arches!slacking}\index{arch!mips}
References:
\begin{itemize}
\item
\dev{caleb}'s post: http://article.gmane.org/gmane.linux.gentoo.devel/53933
(dead link)\footnote{Likely the
\agoref{gentoo-dev}{c32c17977368bc02019bc8318df40dfc}}
\item
\dev{kumba}'s comment on mips status:
http://article.gmane.org/gmane.linux.gentoo.devel/54168 (dead
link)\footnote{Likely the
\agoref{gentoo-dev}{6196880b1c05412836850b2476aacdc1}}
\item
\dev{rich0}'s proposal: http://article.gmane.org/gmane.linux.gentoo.devel/54103
(dead link)\footnote{Can't find it in the archive. It seems to have involved
timeouts of some sorts.}
\end{itemize}
\dev{vapier} will work on \dev{rich0}'s suggestion and repost it for discussion
on the gentoo-dev mailing list.
\agendaitem{Code of Conduct}
\index{Code of Conduct!enforcement}\index{project!devrel}
\index{project!userrel}
References:
\begin{itemize}
\item
\agoref{gentoo-council}{cbfe572adb090dfba1cc004b1cca6979} (for the
attachment see \ref{2007-11-dberkholz-coc})
\item
November 2007 Council meeting
\item
December 2007 Council meeting
\end{itemize}
What needs to happen for us to make a decision?
Last week, we agreed to just add moderators to \#gentoo-dev and the gentoo-dev
list. Other places with their own moderation should enforce the CoC themselves.
We also agreed that moderation must be handed over to devrel or userrel after 2
days.
\dev{fmccor} asked some questions:
\begin{enumerate}
\item
Do we have an implementation schedule?
\item
Have we identified some warm bodies for it?
\item
Most devrel requests seem really to relate to CoC violations. Would you like us
to bounce those to the CoC people, process them using CoC rules, or keep doing
what we are doing now (generally, close them with a note explaining why or
mediate them)? (I'm talking about the "He's being rude / sarcastic /
disrespectful" sorts of things which really need to be processed immediately
and merit a warning or brief suspension if anything.)\footnote{This question is
not in the meeting log.}
\end{enumerate}
Council members agreed on the direction; \dev{dberkholz} will provide
additional details on the gentoo-council mailing list.
\agendaitem{Document of being an active developer}
\index{developer certificate}\index{trustees}\index{Foundation}
\dev{araujo} raised that he needs some kind of written document of being an
active developer. His argument was that mentioning this in a CV in his
environment is only accepted if there is some kind of proof. Our trustee
\dev{grant} deferred it back to council and infra as the Foundation only handles
IP, but suggested it could be some kind of generated document.
One suggested option how to handle this in an automated fashion would be to log
in to dev.gentoo.org and automatically generate the document there, signed by
an infra-maintained key; put userinfo.xml website in the document as reference.
\dev{dberkholz} and \dev{araujo} will look into a scribus based template. devrel
will have to generate a signing key for these purposes.\footnote{Also having
the council sign it with, e.g., a "Gentoo Council Signing Key 2007-2008" was
discussed.}
|
GitWeb