Roll call
---------

(here, proxy [by whom] or slacker?)

amne        here
betelgeuse  here
dberkholz   proxy [musikc]
flameeyes   here
lu_zero     here 
vapier      here
jokey       here 

Agenda
------

GLEP 54: scm package version suffix
	http://www.gentoo.org/proj/en/glep/glep-0054.html

GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
	http://www.gentoo.org/proj/en/glep/glep-0055.html

Code of Conduct enforcement 
	http://thread.gmane.org/gmane.linux.gentoo.council/82
	http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt
	http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt

	- What needs to happen for us to make a decision?

	Last week, we agreed to just add moderators to #gentoo-dev and the
	gentoo-dev list. Other places with their own moderation should enforce the
	CoC themselves. We also agreed that moderation must be handed over to devrel
	or userrel after 2 days.

	Ferris asked some questions:
		1)  Do we have an implementation schedule? ;
		2)  Have we identified some warm bodies for it?;
		3)  Most devrel requests seem really to relate to CoC violations.  Would
		you like us to bounce those to the CoC people, process them using CoC
		rules, or keep doing what we are doing now (generally, close them with a
		note explaining why or mediate them)?  (I'm talking about the "He's
		being rude/sarcastic/disrespectful" sorts of things which really need to
		be processed immediately and merit a warning or brief suspension if
		anything.)

Slacker arches
	See Caleb's post on -dev and subsequent thread
	Calebs post:
	  http://article.gmane.org/gmane.linux.gentoo.devel/53933
	Kumba's comment on mips status:
	  http://article.gmane.org/gmane.linux.gentoo.devel/54168
        Rich0's proposal:
	  http://article.gmane.org/gmane.linux.gentoo.devel/54103


Document of being an active developer
        Araujo raised that he needs some kind of written document of being an
	active developer. Argument being that mentioning in CV in his
	environment is only accepted if there is some kind of proof.
	Our trustee grant deferred it back to council+infra as Foundation only
	handles IP, but suggested it could be some kind of generated document.


=======================================================================

GLEP 54 : Postponed to -dev ML
-------
        Comment from portage maintainer:
	- no statement about compatibility/implementation plans
	- more subjective:
	  - while a distinction between CPV and atom may not be technically
	    required, I might be useful to have
	  - (minor) if the version part is optionl there could be some
	    complications

	So is this something we'd like to have?

        Other ideas that came up during discussion:
        - -scm or _scm ?
	- handling as (-|_pre)9999) versions per definition
	- implement as dynamic package sets

        Related bugs:
	- bug #9202 - Better support for CVS Ebuilds...

	Pushed back to -dev ML as there are too many unresolved questions at
	the moment. peper is given the task to repost it and expand on
	usefulness / use cases as well as compatibility issues.

GLEP 55 : Postponed to -dev ML
-------
        - Agreement on eapi subdirectories are not feasible

	Ideas during discussion:
	- moving from EAPI= to eapi function and using repository bashrc for
	  compatibility

	Pushed back to -dev ML as there are too many unresolved questions at
	the moment.

Slacker arches
--------------
        vapier will work on rich0's suggestion and repost it for discussion on
	-dev ML

Code of Conduct enforcement : 
---------------------------
        Council members agreed on the direction, dberkholz will provide
	additional details on -council ML

Document of being an active developer
-------------------------------------
        Suggested options:
	 - Log in to dev.g.o and automatically generate there signed by
	   infra-maintained key, put userinfo.xml website in the doc as
	   reference.
	 
	 dberkholz and araujo will look into a scribus based template.
	 devrel will have to generate a signing key for these purposes.