\summary{2009}{2}{12} Agenda call: \agoref{gentoo-dev}{221d6a37687a1512034bb2757c560d0a} Agenda announcement: ? \agendaitem{Should the council have a dedicated secretary?} \index{council!secretary} 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. \agendaitem{Council Elections} \index{council!election} Should there be staggered elections every 6 months where half the council members stand for reelection? 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? 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} 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. \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. \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. \dev{cardoe} will follow this up with \dev{dev-zero} as a backup. \agendaitem{Open Bugs} \begin{itemize} \item \bug{234711}: \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}: 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}