summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'decisions/summary-20090212.tex')
-rw-r--r--decisions/summary-20090212.tex115
1 files changed, 56 insertions, 59 deletions
diff --git a/decisions/summary-20090212.tex b/decisions/summary-20090212.tex
index 1868c13..63f00f7 100644
--- a/decisions/summary-20090212.tex
+++ b/decisions/summary-20090212.tex
@@ -1,64 +1,70 @@
\summary{2009}{2}{12}
+Agenda call: \agoref{gentoo-dev}{221d6a37687a1512034bb2757c560d0a}
+
+Agenda announcement: ?
+
+
+
\agendaitem{Should the council have a dedicated secretary?}
\index{council!secretary}
- Previously dberkholz fulfilled this roll, but he became busy.
- Because fulfilling the secretary duties can distract from the
- meeting, a dedicated, non-council member secretary is ideal.
+Previously \dev{dberkholz} fulfilled this role, but he became busy. Because
+fulfilling the secretary duties can distract from the meeting, a dedicated,
+non-council member secretary is ideal.
+
+Conclusion: \dev{tanderson} volunteered and is the new secretary. Logs and
+summary are to be posted on the -council mailing list. If no objections to them
+are raised within one day, they are posted to the council page and the lists.
- Conclusion:
- tanderson is the new secretary. Logs and summary are to be
- posted on the -council mailing list. If no objections to it
- are raised in 1 day, it is posted to the council page and lists.
\agendaitem{Council Elections}
\index{council!election}
- Should there be staggered elections every 6 months where half the
- council members stand for reelection?
+Should there be staggered elections every 6 months where half the council
+members stand for reelection?
- Conclusion:
- Leave as-is, elections every 6 months is too cumbersome. Full elections
- will be held once a year.
+Conclusion: Leave things as they are; elections every 6 months is too
+cumbersome. Full elections will be held once a year.
- What happens if there aren't enough candidates nominated to fill all
- the council seats?
+What happens if there aren't enough candidates nominated to fill all the
+council seats?
- Conclusion:
- If the pseudo-candidate '_reopen_nominations' appears in 7th place
- or higher those candidates that rank above '_reopen_nominations'
- will be the current council. A second period of nominations will
- be opened for the remaining council seats. No third period of
- nominations will be opened in the event '_repoen_nominations'
- ranks higher than the candidates necessary to fill the council.
+Conclusion: If the pseudo-candidate '_reopen_nominations' appears in 7th place
+or higher those candidates that rank above '_reopen_nominations' will be the
+current council. A second period of nominations will be opened for the remaining
+council seats. No third period of nominations will be opened in the event
+'_reopen_nominations' ranks higher than the candidates necessary to fill the
+council.
\agendaitem{Prepalldocs}
\index{prepalldocs}\index{EAPI!0}\index{EAPI!1}\index{EAPI!2}
- Should 'prepalldocs' be allowed in current EAPIs?
+Reference: \bug{250077}
+
+Should 'prepalldocs' be allowed in current EAPIs?
+
+Conclusion: Prepalldocs is banned in current EAPIs (0, 1, 2). It should be
+removed from ebuilds. \dev{betelgeuse} will make QA checks for repoman.
+
- Conclusion:
- Prepalldocs is banned in current EAPIs(0,1,2). It should be
- removed from ebuilds. Petteri R├Ąty(Betelgeuse) will make QA
- checks for repoman.
\agendaitem{BASH version allowed in the tree}
\index{bash!features in ebuilds}\index{PMS}
- PMS states that ebuilds can only rely on BASH 3.0 features. However,
- some code in gentoo-x86 uses BASH 3.1 features('+=' being the most
- notable) and so is not in conformance with PMS. It was suggested that
- BASH versions newer than 3.0 be allowed in a future EAPI. Ciaran
- Mccreesh, however, commented that this would require GLEP 55 being
- accepted so that a package manager would not have to source the ebuild
- before knowing what BASH version it requires.
+PMS states that ebuilds can only rely on BASH 3.0 features. However, some code
+in gentoo-x86 uses BASH 3.1 features('+=' being the most notable) and so is not
+in conformance with PMS. It was suggested that BASH versions newer than 3.0 be
+allowed in a future EAPI. \dev{ciaranm}, however, commented that this would
+require \glep{55} being accepted so that a package manager would not have to
+source the ebuild before knowing what BASH version it requires.\footnote{This
+discussion cannot be found in the meeting log. However, it is referenced in the
+meeting log during the ``open bugs'' discussion.}
- Conclusion:
- No decision. Doug(Cardoe) will follow this up with
- Tiziano(dev-zero) as a backup.
+Conclusion: No decision. \dev{cardoe} will follow this up with \dev{dev-zero}
+as a backup.
\agendaitem{Open Bugs}
@@ -66,29 +72,20 @@
\begin{itemize}
\item
\bug{234711}:
- GLEP 54 solves two problems, version ordering and periodic reinstall
- of live packages. The Live Template proposal
-\url{http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst} overlaps in that it
-also
- allows for periodic reinstall of live packages. Luca(lu_zero)
- maintains that Live Template provides proper version ordering, while
- Ciaran(ciaranm) maintains that it does not.
-
- Conclusion:
- No decision. The council cracked the whip on Luca(lu_zero) and
- he's going to handle the issue.
+ \glep{54} solves two problems, version ordering\footnote{This was actually a
+ matter of debate during the meeting.} and periodic reinstall of live packages.
+ The Live Template proposal
+ http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst\footnote{See
+ \ref{2000-02-luzero-live} for the text.} overlaps in that it also allows for
+ periodic reinstall of live packages. \dev{lu_zero} maintains that Live Template
+ provides proper version ordering, while \dev{ciaranm} maintains that it does
+ not.\\
+ Conclusion: No decision. The council cracked the whip on \dev{lu_zero} and
+ he is going to handle the issue.
\item
- GLEP 55(.ebuild-\$eapi ebuild suffix)
-
- Should .ebuild-\$eapi be approved? This ties in with "BASH version
- allowed in the tree" issue mentioned above.
-
- Conclusion:
- No decision. Tiziano(dev-zero) will be handling this bug.
+ \glep{55}: Should .ebuild-\$eapi be approved? This ties in with "BASH version
+ allowed in the tree" issue mentioned above.\\
+ Conclusion: No decision. \dev{dev-zero} will be handling this bug.
+\end{itemize}
- \item
- Code of Conduct
- Conclusion:
- No decision. Donnie(dberkholz) will be handling this bug.
-\end{itemize}