Index 2007/12 to 2008/5

1 files changed, 142 insertions, 0 deletions

diff --git a/decisions/summary-20080110.tex b/decisions/summary-20080110.tex
new file mode 100644
index 0000000..c4bebc5
--- /dev/null
+++ b/decisions/summary-20080110.tex
@@ -0,0 +1,142 @@
+
+\summary{2008}{1}{10}
+
+
+\agendaitem{GLEP 54: scm package version suffix}
+\index{scm 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.