\summary{2008}{1}{10}


\agendaitem{GLEP 54: scm package version suffix}
\index{scm version suffix}\index{CPV}

Reference: \glep{54}

Comment from portage maintainer:
\begin{itemize}
 \item 
 no statement about compatibility/implementation plans
 \item
 more subjective:
 \begin{itemize}
  \item while a distinction between CPV and atom may not be technically
	    required, I might be useful to have
  \item (minor) if the version part is optionl there could be some
	    complications
 \end{itemize}
\end{itemize}

So is this something we'd like to have?

Other ideas that came up during discussion:
\begin{itemize}
 \item 
 -scm or _scm ?
 \item
 handling as (-|_pre)9999) versions per definition
 \item
 implement as dynamic package sets
\end{itemize}

Related bugs: \bug{9202}

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.


\agendaitem{GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)}

Reference: \glep{55}

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.



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

References: 
\begin{itemize}
 \item 
 Calebs post:
	  http://article.gmane.org/gmane.linux.gentoo.devel/53933 (dead link)
 \item
 Kumba's comment on mips status:
	  http://article.gmane.org/gmane.linux.gentoo.devel/54168 (dead link)
 \item
 Rich0's proposal:
	  http://article.gmane.org/gmane.linux.gentoo.devel/54103 (dead link)
\end{itemize}

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



\agendaitem{Code of Conduct}
\index{Code of Conduct!enforcement}


References: 
\begin{itemize}
 \item 
	http://thread.gmane.org/gmane.linux.gentoo.council/82 (dead link)
 \item
	http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt
 \item
	http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt
\end{itemize}

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:
\begin{enumerate}
\item Do we have an implementation schedule? ;
\item Have we identified some warm bodies for it?;
\item  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.)
\end{enumerate}


        Council members agreed on the direction, dberkholz will provide
	additional details on -council ML




\agendaitem{Document of being an active developer}
\index{developer certificate}

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.



Suggested option: 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.