
\summary{2010}{12}{18}

Agenda call: ---

Agenda announcement: \agoref{gentoo-project}{30e33692f20e77c86977cc52e14ab9b5}


\agendaitem{slacking arches}
\index{arches!slacking}\index{arches!hardware}\index{foundation}

This had been proposed by \dev{scarabeus}. As he wasn't around, the remaining 
council members shifted the focus to making sure there is enough relevant 
hardware available to developers to allow arch team work and questioned whether 
emulation could help on this, at least for non core parts on a trial basis.

\dev{neddyseagoon} asked what hardware is needed and whether there should be a
funding application to the Foundation. \dev{chainsaw} mentioned some hardware 
that could be used by the ppc64 team, and \dev{jmbsvicetto} noted that 
mainstream arches such as amd64 and x86 may also want to make a funding request.

Finally, there was a mention that if council cared about this issue, one member
could talk to arch teams to determine the hardware requirements and that we could
take this opportunity to consider automated test boxes and rethink the boxes for
the weekly builds. This issue was sent back to the mailing list for further
debate.


\agendaitem{la files removal status / progress}
\index{.la files}\index{package!sys-devel/libtool}
\index{package!sys-apps/portage}

\dev{jmbsvicetto} mentioned that portage-2.1.9* is now marked stable, but that
hadn't taken care of the documentation and or submitting a news item proposal 
based on the previous proposal made by \dev{flameeyes} so far. He suggested to
the other council members that the council could either set a deadline to get a 
news item submitted for review on the gentoo-devel mailing list after which the 
.la files removal "embargo" would be dropped or that the "embargo" could just be
dropped immediately, dealing with the consequences afterwards.

\vote{The council will drop the "embargo" on .la file removal if no one submits 
to the gentoo-devel mailing list a news item proposal about this issue before 
23:59 UTC next Wednesday.}{Passed with 3 yes votes and 2 no votes.}


\agendaitem{Arfrever's suggestions for EAPI 4}
\index{EAPI!4}\index{GLEP!55}

Reference: \agoref{gentoo-dev}{bec5db8373fca0271fcadf0cd55724e8}

After some confusion caused by \dev{jmbsvicetto} introducing the 
pkg_required_use topic (see next section below) here, the council members agreed 
to go over each of the points in \dev{arfrever}'s email. \dev{ferringb} took the
occasion to go over  each of the points to finally get the discussion about them 
on record.

\index{use flags!dot character}
Problem \#1: USE flags cannot contain "." characters.

\dev{ferringb} argued that having "." on use flags is simply an aesthetic issue.
Furthermore, use flags are used all over the tree and this could cause backward 
compatibility issues. Thus this would provide a minor gain, but would require
much pain.

Even though the council members agree that it would be possible to find ways to 
allow for the use of "." in use flags and that the change itself, as tracked in
\bug{311795}, would be welcome, they agreed that this should only be addressed 
as part of a major restructuring of use flags, like the introduction of use 
groups.\footnote{Does anyone remember what ``use groups'' were supposed to be?}
\dev{betelgeuse} opened \bug{349021} for this.

The council voted against the proposed solution for this problem with 5 no 
votes.

Problem \#2: Files in profiles cannot use features from newer EAPIs.
\index{EAPI suffix}\index{EAPI!usage in profiles}

\dev{ferringb} argued that \dev{arfrever}'s proposal for "-\$\{EAPI\}" extension
files in the profiles is a nightmare and that it relied on developers to get 
things right across multiple EAPI versions. \dev{jmbsvicetto} and \dev{wired} 
argued that this proposal is another variation of \glep{55} and that they have 
expressed their dislike for it before.

The council voted against  "-\$\{EAPI\}" extension files in the profiles with 5 
no votes.

The proposal to create new profiles using EAPI="4", remove all older profiles 
from profiles.desc so that repoman doesn't check them anymore, and deprecate the 
older profiles was also defeated with 4 no votes and 1 vote to defer to the
mailing list.

During this discussion there was a "detour" into the issue of migrating the EAPI
of the base profiles, moving trouble files like package.mask to real profiles 
and how to ensure a clean upgrade path for old installs. \dev{wired} talked 
about an automated incremental process with switches of rsync sources over time 
and \dev{ferringb} mentioned the use of repository format markers. This 
discussion was pushed back to the mailing list.

Problem \#3: repoman does not allow stable packages to have optional 
dependencies on unstable packages (usually until these packages are stabilized).
\index{use.unsatisfiable}\index{package.use.unsatisfiable}
\index{profiles!per stable status}

\dev{ferringb} argued that both proposed solutions for this problem would cause a 
maintenance "hell" and would have a noticeable repoman run-time impact. 
\dev{betelgeuse} noted he saw a problem needing a solution in here, and 
\dev{jmbsvicetto} argued that the solutions presented need a debate but that 
they are not tied to the presented problem of python versions.

\index{use flags!unstable}\index{optional dependencies}
During the discussion \dev{betelgeuse} asked about a third option, unstable use 
flags, and \dev{jmbsvicetto} argued that separate profiles for stable / unstable
tree could make sense if we got back to the idea of moving KEYWORDS out of 
ebuilds.

In the end the council voted with 5 no votes for both solutions presented in 
point 3 to be part of the EAPI-4 specification.


\agendaitem{pkg_required_use}
\index{pkg_required_use}\index{REQUIRED_USE}

Reference: \agoref{gentoo-project}{3463900fd31abf9894c4c07e1a4a9978}

After a first attempt to discuss this during the previous point, the council
addressed this issue after \dev{ulm} recalled he requested it to be added to the
agenda, which \dev{jmbsvicetto} forgot to do.

Following some debate about this issue, including requested feedback from both
\dev{zmedico} and \dev{ferringb}, the council voted on having EAPI-4 introduce a 
pkg_required_use function to be called by the PM when it can't fulfill the 
REQUIRED_USE constraints with 4 no votes and 1 yes vote. The council members 
accepted having an EAPI-4.1 with pkg_required_use if / when there is a need for
it in the tree.

The council also expressed the desire to get a final vote on EAPI-4 before the 
end of the year. \dev{betelgeuse} will propose a schedule to get EAPI-4 voted 
through email.


\agendaitem{Open bugs}

As the meeting lasted over 2 hours, the productivity was becoming low, and 
\dev{betelgeuse} had to leave, the review of the open bugs was pushed to the 
next meeting.


\agendaitem{Open floor}

No items were brought to the attention of the council at this meeting.
