Start improving 5/2008, WIP

6 files changed, 120 insertions, 131 deletions

diff --git a/decisions/decisions.ded b/decisions/decisions.ded
index 1328bb2..8ea98b4 100644
--- a/decisions/decisions.ded
+++ b/decisions/decisions.ded
@@ -79,6 +79,9 @@ Danny van Dyk
 kumba
 Joshua Kinard
 https://wiki.gentoo.org/wiki/User:Kumba
+leio
+Mart Raudsepp
+https://wiki.gentoo.org/wiki/User:Leio
 lu_zero
 Luca Barbato
 https://wiki.gentoo.org/wiki/User:Lu\%20zero
@@ -127,6 +130,9 @@ Roy Marples
 vapier
 Mike Frysinger
 https://wiki.gentoo.org/wiki/User:Vapier
+welp
+Peter Weller
+
 wolf31o2
 Chris Gianelloni
 
diff --git a/decisions/decisions.kilepr b/decisions/decisions.kilepr
index fa21b69..979ebe2 100644
--- a/decisions/decisions.kilepr
+++ b/decisions/decisions.kilepr
@@ -4,7 +4,7 @@ img_extIsRegExp=false
 img_extensions=.eps .jpg .jpeg .png .pdf .ps .fig .gif
 kileprversion=2
 kileversion=2.1.3
-lastDocument=summary-20080410.tex
+lastDocument=summary-20080508.tex
 masterDocument=
 name=Gentoo Council Decicisions Index
 pkg_extIsRegExp=false
@@ -1193,10 +1193,10 @@ order=1
 
 [item:decisions.ded]
 archive=true
-column=15
+column=38
 encoding=UTF-8
 highlight=None
-line=37
+line=83
 mode=
 open=true
 order=2
@@ -1558,18 +1558,18 @@ encoding=UTF-8
 highlight=LaTeX
 line=94
 mode=LaTeX
-open=true
+open=false
 order=5
 
 [item:summary-20080508.tex]
 archive=true
-column=0
+column=32
 encoding=UTF-8
 highlight=LaTeX
-line=0
+line=140
 mode=LaTeX
-open=false
-order=-1
+open=true
+order=5
 
 [item:summary-20080515.tex]
 archive=true
@@ -2838,10 +2838,10 @@ JumpList=
 ViMarks=.,15,23,[,15,21,],15,23
 
 [view-settings,view=0,item:decisions.ded]
-CursorColumn=15
-CursorLine=37
+CursorColumn=38
+CursorLine=83
 JumpList=
-ViMarks=.,37,0,[,35,0,],37,14
+ViMarks=.,83,0,[,83,0,],83,37
 
 [view-settings,view=0,item:decisions.gld]
 CursorColumn=26
@@ -3060,10 +3060,10 @@ JumpList=
 ViMarks=.,21,36,[,21,33,],21,36
 
 [view-settings,view=0,item:summary-20080508.tex]
-CursorColumn=0
-CursorLine=0
+CursorColumn=32
+CursorLine=140
 JumpList=
-ViMarks=
+ViMarks=.,137,11,[,137,5,],137,11
 
 [view-settings,view=0,item:summary-20080515.tex]
 CursorColumn=0
diff --git a/decisions/decisions.mlf b/decisions/decisions.mlf
index 150091f..1e02471 100644
--- a/decisions/decisions.mlf
+++ b/decisions/decisions.mlf
@@ -254,6 +254,8 @@ ba2cdfa0060c1a2b7583e19185564855:gentoo-dev
 Mike Frysinger
 bc0a1b7498c389bdbb0b0d52feb43391:gentoo-project
 Ulrich Mueller
+bd9a171d7303bf1299a4c307f7b6ddcf:gentoo-dev
+Mike Frysinger
 bec5db8373fca0271fcadf0cd55724e8:gentoo-dev
 Arfrever Frehtes Taifersar Arahesis
 c32c17977368bc02019bc8318df40dfc:gentoo-dev
diff --git a/decisions/decisions.mls b/decisions/decisions.mls
index 749516c..d5cf773 100644
--- a/decisions/decisions.mls
+++ b/decisions/decisions.mls
@@ -254,6 +254,8 @@ ba2cdfa0060c1a2b7583e19185564855:gentoo-dev
 [gentoo-dev] Monthly Gentoo Council Reminder for December
 bc0a1b7498c389bdbb0b0d52feb43391:gentoo-project
 Re: [gentoo-project] Call for Agenda Items -- Council Meeting 2016-01-10
+bd9a171d7303bf1299a4c307f7b6ddcf:gentoo-dev
+[gentoo-dev] Monthly Gentoo Council Reminder for May
 bec5db8373fca0271fcadf0cd55724e8:gentoo-dev
 [gentoo-dev] Summary of suggested new features in EAPI="4"
 c32c17977368bc02019bc8318df40dfc:gentoo-dev
diff --git a/decisions/decisions.mlt b/decisions/decisions.mlt
index 77b275c..a876190 100644
--- a/decisions/decisions.mlt
+++ b/decisions/decisions.mlt
@@ -254,6 +254,8 @@ ba2cdfa0060c1a2b7583e19185564855:gentoo-dev
 Sat, 01 Dec 2007 10:48:04
 bc0a1b7498c389bdbb0b0d52feb43391:gentoo-project
 Sun, 27 Dec 2015 18:03:56
+bd9a171d7303bf1299a4c307f7b6ddcf:gentoo-dev
+Thu, 01 May 2008 09:30:05
 bec5db8373fca0271fcadf0cd55724e8:gentoo-dev
 Sat, 18 Dec 2010 01:45:51
 c32c17977368bc02019bc8318df40dfc:gentoo-dev
diff --git a/decisions/summary-20080508.tex b/decisions/summary-20080508.tex
index cee6619..72aac79 100644
--- a/decisions/summary-20080508.tex
+++ b/decisions/summary-20080508.tex
@@ -1,31 +1,34 @@
 
 \summary{2008}{5}{8}
 
+Agenda call: \agoref{gentoo-dev}{bd9a171d7303bf1299a4c307f7b6ddcf}
+
 
 \agendaitem{New process}
 
-The last few meetings have dragged out for hours unnecessarily. This 
-time, we tried moderating the channel during discussion of each topic, 
-then temporarily opening the floor for that topic before a vote so 
-anyone could contribute. Here's the time breakdown:
-
-\begin{verbatim}
-	2000-2030: closed, 30 min
-	2030-2046: open, 16 min
-	2046-2056: closed, 10 min
-	2056-2114: open, 18 min
-	2114-2146: closed, 32 min
-	2146-2209: open, 23 min
-	2209-2242: closed, 33 min
-	2242-    : open floor 
-\end{verbatim}
+The last few meetings have dragged out for hours unnecessarily. This time, we 
+tried moderating the channel during discussion of each topic, then temporarily 
+opening the floor for that topic before a vote so anyone could contribute. 
+Here's the time breakdown:
+\begin{center}
+ \begin{tabular}{c|c|c|c}
+  start & end & mode & duration \\ \hline
+  20:00 & 20:30 & closed & 30min \\
+  20:30 & 20:46 & open   & 16min \\
+  20:46 & 20:56 & closed & 10min \\
+  20:56 & 21:14 & open   & 18min \\
+  21:14 & 21:46 & closed & 32min \\
+  21:46 & 22:09 & open   & 23min \\
+  22:09 & 22:42 & closed & 33min \\
+  22:42 &       & \multicolumn{2}{c}{open floor}
+ \end{tabular}
+\end{center}
 
 Total before open floor: 105 minutes closed, 57 minutes open.
 
 Optimistically, we could have saved an hour if the channel was moderated 
-throughout the meeting. That's unlikely to be the case in reality, 
-because we'd be redirecting people's comments from queries into the 
-channel.
+throughout the meeting. That's unlikely to be the case in reality, because we 
+would be redirecting people's comments from queries into the channel.
 
 Should we keep it moderated until the final open floor? Should we have 
 an open "backchannel"?
@@ -34,48 +37,34 @@ an open "backchannel"?
 \agendaitem{Document of being an active developer}
 \index{developer certificate}
 
+\dev{araujo} made http://dev.gentoo.org/$\sim$araujo/gcert1.pdf in Scribus. 
+He'd like to ask for approval of this design and discuss the script, in 
+particular its infrastructure requirements.
 
-Last month:
-		No updates
-
-Updates:
-		araujo made http://dev.gentoo.org/~araujo/gcert1.pdf in Scribus. 
-		He'd like to ask for approval of this design and discuss the 
-		script, in particular its infrastructure requirements.
-
-Suggestions on certificate content:
+Suggestions on the certificate content were:
 \begin{itemize}
-\item Add title to the top: "Developer Certification"
+\item Add a title to the top: "Developer Certification"
 \item Add devrel contact info (general devrel email address)
-\item Add link to devrel userinfo page
-\item Add start and end dates to devrel retired developers 
-page
-\item Add a sentence saying e.g. "This certifies that XXX was 
-a 
-			 Gentoo developer from START_DATE to TODAY_DATE." The point 
-			 is to avoid implying that the developer is certified 
-			 forever, or will be a developer in the future.
-
-The information should be gotten from LDAP, for example using 
-		python-ldap. Could base this script on devrel's slacker script.
-
-It's unsure how signatures are going to happen, but one option 
-		is to keep a GPG-encrypted image of a signature and decrypt it 
-		on-demand for certificate creation. This should be discussed 
-		with the person doing the signing.
+\item Add a link to the devrel userinfo web page
+\item Add start and end dates on the devrel retired developers web page
+\item Add a sentence saying e.g. "This certifies that XXX was a Gentoo 
+developer from START_DATE to TODAY_DATE." 
+
+The point is to avoid implying thatthe developer is certified forever, or will 
+be a developer in the future. This information should be gotten from LDAP, for 
+example using python-ldap. One could base this script on devrel's slacker 
+script.
 \end{itemize}
 
-\agendaitem{Slacker arches}
-\index{arches!slacking}
-
-4 months ago: vapier will work on rich0's suggestion and repost it for 
-discussion on -dev ML
+It is unsure how signatures are going to happen, but one option is to keep a 
+GPG-encrypted image of a signature and decrypt it on-demand for certificate 
+creation. This should be discussed with the person doing the signing.
 
-2 months ago: vapier said he was going to work on it that weekend.
 
-Last month: No updates
+\agendaitem{Slacker arches}
+\index{arches!slacking}
 
-Updates: ---
+There were no updates on this topic. 
 
 
 \agendaitem{When are ChangeLog entries required?}
@@ -83,35 +72,29 @@ Updates: ---
 
 This question mainly relates to arch stabilizations.
 
-The consensus was that ChangeLog entries even for arch 
-	stabilizations provide valuable information that is unique without 
-	network access and more accessible than CVS logs even with network 
-	access.
+The consensus was that ChangeLog entries even for arch stabilizations provide 
+valuable information that is unique without network access and more accessible 
+than CVS logs even with network access. So, ChangeLog entries are always 
+required. If you aren't making them now, fix your script to call echangelog.
 
-So, Always required. If you aren't making them now, fix 
-your script to call echangelog.
+Some people were curious what proportion of space ChangeLogs take in the tree, 
+but most people didn't think that was relevant.
 
-Some people were curious what proportion of space ChangeLogs take in 
-	the tree, but most people didn't think that was relevant.
-
-welp suggested making a changelog message part of repoman commit.
-
-It would be helpful for the QA team to help with checking for and 
-	enforcing ChangeLog messages. If that doesn't help matters, the 
-	council may have to take action.
+\dev{welp} suggested making a changelog message part of repoman commit.
+It would be helpful for the QA team to help with checking for and enforcing 
+ChangeLog messages. If that doesn't help matters, the council may have to take 
+action.
 
 
 \agendaitem{Can the council help fewer bugs get ignored by arm/sh/s390 teams?}
 \index{arch!arm}\index{arch!sh}\index{arch!s390}
 
-The work happens, but Mart says it's not communicated to anyone and 
-	has no relationship to whether bugs are open.
+The work happens, but \dev{leio} says it is not communicated to anyone and has 
+no relationship to whether bugs are open. We need to understand the workflow of 
+undermanned arch teams and see whether there's anything we can help improve.
 
-We need to understand the workflow of undermanned arch teams and see 
-	whether there's anything we can help improve.
-
-Possibly improving recuitment -- add a good, motivating 
-	staffing-needs entry.
+Possibly improving recuitment -- we should add a good, motivating 
+staffing-needs entry.
 
 
 \agendaitem{PMS: Are versions allowed to have more than 8 digits?}
@@ -124,57 +107,51 @@ References:
  \bug{188449}
 \end{itemize}
 
-What do various PMs/tools support? Portage, Pkgcore, Paludis all 
-	handle >8. portage-utils does not but could be fixed to use longs 
-	instead of ints, with some loss of performance (magnitude unclear).
-
-versionator.eclass also needs fixing for >8 digits.
-
-Apparently [ ]-style tests break with large numbers, but [[ ]] 
-	works. Have to be careful which tests are getting used anywhere 
-	large versions are compared.
-
-The council generally favored allowing versions to have <=18 digits. 
-	This allows them to fit into 64 bits (18 signed digits or 19 
-	unsigned) and gives them an upper bound, which some implementations 
-	of version parsing could find useful.
-
-We voted to do more research and testing, specifically to ask the 
-	package maintainers with extremely long PVs whether they were needed 
-	and to test the impact of extending versionator.eclass. The involved 
-	packages:
-
-\begin{verbatim}
-		sys-process/fuser-bsd
-		sys-apps/net-tools
-		sys-apps/gradm
-		net-im/ntame
-		media-video/captury
-		media-libs/libcaptury
-		media-libs/capseo
-		sys-block/btrace
-		www-apache/mod_depends
-		net-wireless/rt2500
-		sys-fs/unionfs
-\end{verbatim}
+What do various package managers / tools support? \package{sys-apps/portage}, 
+\package{sys-apps/pkgcore}, and \package{sys-apps/paludis} all handle more 
+than 8 digits. \package{app-portage/portage-utils} does not but could be fixed 
+to use longs instead of ints, with some loss of performance (magnitude unclear).
+versionator.eclass \index{eclass!versionator} also needs fixing for >8 digits.
+Apparently [ ]-style tests break with large numbers, but [[ ]] works. We have 
+to be careful which tests are getting used anywhere large versions are compared.
+
+The council generally favored allowing versions to have $<=18$ digits. This 
+allows them to fit into 64 bits (18 signed digits or 19 unsigned) and gives them 
+an upper bound, which some implementations of version parsing could find useful.
+
+We voted to do more research and testing, specifically to ask the package 
+maintainers with extremely long PVs whether they were needed and to test the 
+impact of extending versionator.eclass. The involved packages are:
+
+\begin{itemize}
+\item \package{sys-process/fuser-bsd}
+\item \package{sys-apps/net-tools}
+\item \package{sys-apps/gradm}
+\item \package{net-im/ntame}
+\item \package{media-video/captury}
+\item \package{media-libs/libcaptury}
+\item \package{media-libs/capseo}
+\item \package{sys-block/btrace}
+\item \package{www-apache/mod_depends}
+\item \package{net-wireless/rt2500}
+\item \package{sys-fs/unionfs}
+\end{itemize}
 
 
 \agendaitem{Enforced retirement}
 \index{retirement!enforced}\index{project!devrel}
 
-The meeting had already gone 2.5 hours and we were short multiple 
-	council members because of the late hour in their timezone, or 
-	broken hardware in the case of jokey. Because of the urgency of 
-	getting this resolved, we decided it couldn't wait for next month's 
-	meeting and scheduled a special session for next week at the same 
-	time.
+The meeting had already gone 2.5 hours and we were short multiple council 
+members because of the late hour in their timezone, or broken hardware in the 
+case of \dev{jokey}. Because of the urgency of getting this resolved, we 
+decided it couldn't wait for next month's meeting and scheduled a special 
+session for next week at the same time.
 
 
 \agendaitem{Open floor}
 \index{retirement!appeal}
 
-	Some people thought that we were going to make a final decision on 
-	the above appeals today, because the agenda was insufficiently clear 
-	on that. That was not the case. What we intended to do was explain 
-	why we can take the appeal and then figure out the process for it
-	because we haven't done any appeals before.
+Some people thought that we were going to make a final decision on the above 
+appeals today, because the agenda was insufficiently clear on that. That was 
+not the case. What we intended to do was explain why we can take the appeal and 
+then figure out the process for it because we haven't done any appeals before.