\summary{2008}{1}{10}

Agenda call: \agoref{gentoo-dev}{6a77b647228fc497a720151fa8a6e54c}


\agendaitem{GLEP 54: scm package version suffix}

Reference: \glep{54}

The proposed GLEP was discussed. Comments from portage maintainer \dev{genone} 
were:
\begin{itemize}
 \item 
 There is no statement about compatibility/implementation plans in the GLEP.
 \item
 While a distinction between CPV and atom may not be technically required, it 
 might be useful to have
 \item
 (minor) If the version part is optional there could be some complications.
\end{itemize}

So is this something we'd like to have (before we decide on details)? The -9999 
version usage in the tree was started since there was no progress on \bug{9202}.

Other (implementation) ideas that came up during discussion:
\begin{itemize}
 \item 
 Should we use a -scm or _scm suffix?
 \item
 Alternatively, handling (-$\vert$_pre)9999) as scm versions per definition?
 \item
 Implement this as dynamic package sets?
\end{itemize}

The topic was pushed back to the gentoo-dev mailing list as there are too many 
unresolved questions at the moment. \dev{peper} is given the task to repost it 
and expand on usefulness / use cases as well as on compatibility issues.


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

Reference: \glep{55}

This resulted in a lengthy discussion on technical advantages and 
disadvantages, including using a pre-sourcing EAPI as mask before providing the 
final EAPI of an ebuild via sourcing, or converting the EAPI assignment to a 
function call and using a repository bashrc for backwards 
compatibility.\footnote{The whole proposal was 
initially kicked off for allowing eclasses to use a different EAPI from an 
ebuild.} There was agreement that EAPI subdirectories are not feasible.

The topic was pushed back to the gentoo-dev mailing list as there are too many 
unresolved questions at the moment.



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

References: 
\begin{itemize}
 \item 
 \dev{caleb}'s post: http://article.gmane.org/gmane.linux.gentoo.devel/53933 
 (dead link)\footnote{Likely the 
 \agoref{gentoo-dev}{c32c17977368bc02019bc8318df40dfc}}
 \item
 \dev{kumba}'s comment on mips status:
 http://article.gmane.org/gmane.linux.gentoo.devel/54168 (dead 
 link)\footnote{Likely the 
 \agoref{gentoo-dev}{6196880b1c05412836850b2476aacdc1}}
 \item
 \dev{rich0}'s proposal: http://article.gmane.org/gmane.linux.gentoo.devel/54103 
 (dead link)\footnote{Can't find it in the archive. It seems to have involved 
 timeouts of some sorts.}
\end{itemize}

\dev{vapier} will work on \dev{rich0}'s suggestion and repost it for discussion 
on the gentoo-dev mailing list.



\agendaitem{Code of Conduct}
\index{Code of Conduct!enforcement}\index{project!devrel}
\index{project!userrel}


References: 
\begin{itemize}
 \item 
 \agoref{gentoo-council}{cbfe572adb090dfba1cc004b1cca6979} (for the 
 attachment see \ref{2007-11-dberkholz-coc})
 \item
 November 2007 Council meeting
 \item
 December 2007 Council meeting
\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.

\dev{fmccor} 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.)\footnote{This question is 
not in the meeting log.}
\end{enumerate}

Council members agreed on the direction; \dev{dberkholz} will provide
additional details on the gentoo-council mailing list.


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

\dev{araujo} raised that he needs some kind of written document of being an
active developer. His argument was that mentioning this in a CV in his 
environment is only accepted if there is some kind of proof. Our trustee 
\dev{grant} deferred it back to council and infra as the Foundation only handles 
IP, but suggested it could be some kind of generated document.

One suggested option how to handle this in an automated fashion would be to log 
in to dev.gentoo.org and automatically generate the document there, signed by 
an infra-maintained key; put userinfo.xml website in the document as reference.

\dev{dberkholz} and \dev{araujo} will look into a scribus based template. devrel 
will have to generate a signing key for these purposes.\footnote{Also having 
the council sign it with, e.g., a "Gentoo Council Signing Key 2007-2008" was 
discussed.}