diff options
Diffstat (limited to 'decisions/summary-20090212.tex')
| -rw-r--r-- | decisions/summary-20090212.tex | 115 |
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} |