blob: 85794b8b55e635122cbf6787060f156edd7a305a (
plain)
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
|
\summary{2009}{9}{14}
Agenda call: ???
Agenda announcement: \agoref{gentoo-council}{96c702e85f79b8f5e22472ae2c961534}
\agendaitem{Update on LiveCD/DVD for Gentoo 10.0}
\index{LiveDVD}\index{anniversary!10 year}
\dev{solar} commmented that things were progressing fine. A new snapshot will
be taken on September 20th and the cutoff date will be the 4th of October.
\agendaitem{A Way to Modify the PMS such that it doesn't directly involve the
EAPI Process}
\index{PMS!modification}
Reference: \bug{273261}, comment 18
\dev{tsunam} requested a decision on a process to modify PMS without involving
the EAPI Process.
There was discussion about whether PMS is a documenting simply documenting the
ebuild API or if it is a broader document covering the entire tree. The agenda
item was deferred until the next meeting to be discussed on mailing lists
beforehand.
\agendaitem{Discussion of the Need for a PMS/EAPI committee outside of the
council}
\index{PMS}
\begin{enumerate}
\item
Either we form a new committee / working group for EAPI and PMS questions (more
or less \dev{calchan}'s proposal). There should be one or two members from
the council, plus someone from the PMS project, and a representative for each
package manager.
\item
In principle also the PMS project could play this role, but with its current
membership of only three developers it is too weak. So some relevant people (see
above) would have to join. On the other hand, there is already a bugzilla alias
(pms-bugs), a mailing list (gentoo-pms) and an IRC channel set up.
\item
Something (completely) different.
\end{enumerate}
Of the three proposals the council chose to do something complete different,
and what will be done will be discussed on lists (in particular gentoo-pms) or
at the next meeting.
|
GitWeb
