
\summary{2010}{12}{18}


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

This subject was proposed by 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.

	Roy (NeddySeagoon) asked what hardware is needed and whether there should be a
	funding application to the Foundation. Tony mentioned some hardware that could
	be used by the ppc64 team and Jorge noted that mainstream arches such as amd64
	and x86 may also want to make a 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 ml for further debate.
	

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


Jorge mentioned that portage-2.1.9* is now marked stable, but that he failed to
	take care of the documentation and or submitting a news item proposal based on
	the previous proposal made by Diego (flameeyes). He suggested the other council
	members that the council could either set a deadline to get a news item submitted
	for review in the dev ml after which the la files removal "embargo" would be
	dropped or just drop the "embargo" immediately and deal with the consequences.

	After some discussion there was a vote on "the council will drop the "embargo" on
	la file removal if no one submits to the dev ml a news item proposal about this
	issue before 2359 UTC next Wednesday". There were 3 yes votes and 2 no votes on
	this proposal.


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

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

After some confusion caused by Jorge introducing the pkg_required_use topic
	during the discussion of this topic, the council members agreed to go over each
	of the points in Arfrever's email. Brian took the occasion to go over 
each of
	the points to finally get the discussion about them on record.

Problem \#1: USE flags cannot contain "." characters.
		
		Brian 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 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. Petteri opened 
\bug{349021} for this.
		
		The council voted against the proposed solution for this problem with 5 votes no.

Problem \#2: Files in profiles cannot use features from newer EAPIs.

		Brian argued that Arfrever's proposal for "-\$\{EAPI\}" 
extension files is a nightmare
		and that it relied on developers to get things right across multiple eapi versions.
		Jorge and Alex argued that this proposal is another variation of GLEP55 and that
		they have expressed their dislike for it before.

		The council voted against both proposed solutions for this problem with 5 votes no
		for the 1st solution and 4 votes no and 1 defer to ml for the 2nd solution.

		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. Alex talked about an automated
		incremental process with switches of rsync sources over time and Brian mentioned the
		use of repository format markers. This discussion was pushed back to the ml.

Problem \#3: repoman doesn't allow stable packages to have optional 
dependencies on unstable
	packages (usually until these packages are stabilized).

		Brian argued that both proposed solutions for this problem would cause a maintenance
		"hell" and would have a noticeable repoman run-time impact. Petteri noted he saw a
		problem needing a solution in here and Jorge argued that the solutions presented need
		a debate but that they are not tied to the presented problem.

		During the discussion Petteri asked about a 3rd option, unstable use flags, and Jorge
		argued that the 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}


	After a first attempt to discuss this during the previous point, the council addressed this
	issue after Ulrich (ulm) recalled he requested it to be added to the topic, which Jorge forgot
	to do.
	
	Following some debate about this issue, including requested feedback from both Zac (zmedico)
	and Brian, 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. Petteri 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 Petteri had to
	leave, the review of the open bugs was pushed for next meeting.


		
\agendaitem{Open floor - listen to the community}

No issue was brought to the attention of the council at this meeting.
