Index 2008/7 to 2009/3

15 files changed, 824 insertions, 1 deletions

diff --git a/decisions/decisions.but b/decisions/decisions.but
index a604e67..fdcdd1e 100644
--- a/decisions/decisions.but
+++ b/decisions/decisions.but
@@ -18,6 +18,8 @@ Document how to change reply-to headers on gentoo lists
 Clarify Foundation page on external entities
 179380
 [EAPI-1] add ECONF_SOURCE support to the default src_compile() function
+185572
+As the proctors no longer exist the code of conduct needs an update
 187971
 Gentoo Website Command Injection Issue
 188449
@@ -30,10 +32,20 @@ EAPI-1 tracker
 a standard way to install includes (doinclude/doheader)
 229521
 [Future EAPI] Add support for multi slot dependencies
+234705
+Document of being an active developer
 234706
 Slacker arches
+234708
+Can the council help fewer bugs get ignored by arm/sh/s390 teams?
+234710
+as-needed by default
 234711
 GLEP 54: scm package version suffix
+234713
+GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)
+234716
+Extent of Code of Conduct enforcement
 237381
 Document appeals process
 256451
diff --git a/decisions/decisions.bux b/decisions/decisions.bux
index ee58c24..0549a7a 100644
--- a/decisions/decisions.bux
+++ b/decisions/decisions.bux
@@ -14,16 +14,28 @@ dynamic SLOT;SLOT!dynamic
 IUSE defaults
 179380
 ECONF_SOURCE
+185572
+Code of Conduct;project!proctors
 188449
 PMS;PMS!version components
 194876
 EAPI!1
 211529
 --disable-dependency-tracking;src_configure;econf
+234705
+developer certificate
 234706
 arches!slacking
+234708
+arch!arm;arch!sh;arch!s390
+234710
+as-needed
 234711
 GLEP!54;scm version suffix;live suffix
+234713
+GLEP!55;EAPI suffix
+234716
+Code of Conduct!extent;Code of Conduct!enforcement
 237381
 council!appeals process
 256453
diff --git a/decisions/decisions.tex b/decisions/decisions.tex
index c57ab7c..9cde354 100644
--- a/decisions/decisions.tex
+++ b/decisions/decisions.tex
@@ -193,6 +193,8 @@ All summaries have been added here.
 Council members: amne, betelgeuse, dberkholz, flameeyes, jokey 
 (starting 11/2007), lu_zero, uberlord (until 10/2007), vapier 
 
+All summaries have been added here.
+
 \include{summary-20071011}
 \include{summary-20071108}
 \include{summary-20071213}
@@ -203,10 +205,27 @@ Council members: amne, betelgeuse, dberkholz, flameeyes, jokey
 \include{summary-20080508}
 \include{summary-20080515}
 \include{summary-20080612}
-\include{summary-20080710}
 
 \chapter{Meeting summaries 2008/09}
 
+Council members: betelgeuse, cardoe (starting 9/2008), dberkholz, dertobi123, 
+flameeyes (until 8/2008), halcy0n (until 12/2/2009), jokey, leio 
+(starting 26/2/2009), lu_zero
+
+\include{summary-20080710}
+\include{summary-20080724}
+\include{summary-20080814}
+\include{summary-20080828}
+\include{summary-20080911}
+\include{summary-20080925}
+\include{summary-20081023}
+\include{summary-20081113}
+\include{summary-20081211}
+\include{summary-20090122}
+\include{summary-20090212}
+\include{summary-20090226}
+\include{summary-20090312}
+
 \chapter{Meeting summaries 2009/10}
 
 Council members: betelgeuse, calchan, dertobi123, leio, scarabeus, solar, ulm
diff --git a/decisions/summary-20080724.tex b/decisions/summary-20080724.tex
new file mode 100644
index 0000000..97f2a00
--- /dev/null
+++ b/decisions/summary-20080724.tex
@@ -0,0 +1,21 @@
+
+\summary{2008}{7}{24}
+
+
+\agendaitem{Userrel authority}
+\index{project!userrel}
+
+Does userrel have the ability to enforce the
+        CoC on users like devrel does for developers?
+
+It was decided that userrel does have this authority.
+
+
+\agendaitem{Code of Conduct extent}
+\index{Code of Conduct!extent}
+
+All council members will review the CoC thread and comment on it by the
+next meeting (7 August 2008).  We will get a status update in that
+meeting to see if we can vote on any of the proposals brought up in that
+thread.
+
diff --git a/decisions/summary-20080814.tex b/decisions/summary-20080814.tex
new file mode 100644
index 0000000..cd736f5
--- /dev/null
+++ b/decisions/summary-20080814.tex
@@ -0,0 +1,165 @@
+
+\summary{2008}{8}{14}
+
+\agendaitem{Unplanned topics}
+\index{council!meeting!default proxies}
+
+All the council members should nominate default proxies.
+
+
+\agendaitem{Reactions to dev banned from freenode}
+\index{freenode}
+
+rane:
+I'd like to ask Council to discuss possible reactions to our developer 
+being banned from Freenode without providing us with a reason. ... It 
+would be good if Council officially protested against that ban and 
+demanded a detailed explanation from Freenode staff.
+
+\begin{verbatim}
+20:14 <   Halcy0n@> Do we have a history of how many times this has happened?  
+                    I believe another dev was klined after this was initially 
+                    brought up.
+20:14 <    musikc > ive spoken with the second dev actually
+20:16 <    musikc > the guy said he'd done what he was told to do and was still 
+                    waiting for some resolution
+20:17 <    musikc > i last spoke to him on the 10th
+\end{verbatim}
+
+
+\agendaitem{Moving meetings to a location we control}
+\index{council!meeting!location}
+
+rane:
+I want Council to consider moving their meetings somewhere where third 
+parties can't control who in Gentoo can attend and who can't. Like our 
+own small and created just for this purpose IRC server.
+
+\begin{verbatim}
+20:26 <    Cardoe > We already have a public ML where predominately a lot of 
+                    the discussion takes place. Is there really any actual 
+                    supression occurring because of our use of Freenode?
+20:26  *    jokey is still not in favour of running an irc network
+20:27 < dberkholz@> Halcy0n: motivation is that when our devs get klined, it's 
+                    really hard for them to work with others on irc
+20:28 < dberkholz@> antarus: as i was saying earlier, freenode is a tool for 
+                    us. if that tool is getting in our way, it needs to change
+20:29 <    Cardoe > dberkholz: the question is the tool getting in our way or 
+                    hindering us. Or will devising our own tool hinder us more..
+20:30 <   Halcy0n@> Cardoe: I think us having to maintain it will be more of a 
+                    headache.
+20:30 <    Cardoe > Halcy0n: I'm in agreement with you on that.
+20:30 <dertobi123@> dito
+20:31 <     jokey@> indeed, let's discuss this there
+20:32 <    Cardoe > We have other things to use manpower on, like developing a 
+                    distribution.
+\end{verbatim}
+
+We currently have 2 freenode group contacts: fmccor and rane.
+
+
+\agendaitem{Favor irc.gentoo.org alias in docs, etc}
+\index{irc.gentoo.org}\index{irc!channel!\#gentoo-java}
+
+rane:
+I want Council to consider creating and using irc.gentoo.org alias 
+instead of irc.freenode.net in our docs, news items and so on. The alias 
+would allow us to move out of the network more easily should we ever 
+decide to do so.
+
+spb brought up a good point to think about.
+\begin{verbatim}
+20:35 <       spb > as people connect to irc.gentoo.org and assume that 
+                    generic-sounding channel names are all about gentoo
+20:35 <Betelgeuse@> spb: And people connect to freenode and assume gentoo-java 
+                    is about generic Java
+20:37 <     jokey@> I'd say at least one user every 3-4 days over in #gentoo-php
+20:37 <Betelgeuse@> jokey: Quite common on #gentoo-java too even with the 
+                    warnings all over the place.
+\end{verbatim}
+
+
+\agendaitem{Banning fired developers}
+\index{enforced retirement}\index{irc!ban}
+
+yngwin:
+It really baffles me that some developers are forcefully retired for 
+anti-social behavior, but are not consequently banned from the places 
+where they display this behavior, such as our MLs and IRC channels. What 
+good is it to retire developers, but allow them to continue to be 
+disruptive? I would like the Council to decide for a change in our 
+policy on this point.
+
+
+\begin{verbatim}
+20:44 <dleverton_ > As I said on the list (maybe too late for anyone to have 
+                    noticed), since yngwin said there were're actually any devs 
+                    that this applies to, is there anything to discuss?
+20:45 < dberkholz@> dleverton_: i must've interpreted his response differently 
+                    from you
+20:45 <    yngwin > i didnt say it like that, dleverton_
+20:45 < dberkholz@> what i understood was that we should ban them from the same 
+                    communication channel
+20:46 < dberkholz@> and allow other ones where they handled themselves 
+                    differently
+\end{verbatim}
+
+spb commented that the three fired devs were actually banned from
+\#gentoo-dev for quite some time.
+
+\begin{verbatim}
+20:51 <    musikc > from a devrel perspective, we do not give voice to every 
+                    dev who is retired so why should a forcibly retired dev be 
+                    any different?
+
+20:51 <     tomaw > Is the council interested in the autodevoice feature or is 
+                    this rambling off topic?
+20:51 <jmbsvicett > tomaw: As long as we stick to freenode, -1 is something 
+                    that interests us
+
+20:52 <    Cardoe+> Standardize a policy for what happens to voluntarily 
+                    retired devs and forcibly retired devs.
+20:53 <    Cardoe+> Can we actually tweak it?
+20:53 <    Cardoe+> the council direct devrel to come up with a proposed 
+                    solution/policy
+20:55 <    musikc > dberkholz, your call. happy to assist by doing work or by 
+                    just stating current process and devrel stance :)
+\end{verbatim}
+
+
+\agendaitem{PMS as a draft standard of EAPI 0}
+\index{PMS}\index{EAPI!0}
+
+spb:
+It should be treated as a draft standard, and any deviations from it 
+found in the gentoo tree or package managers should have a bug filed 
+against either the deviator or PMS to resolve the differences.
+
+Alternatively, what (specific) changes are required to PMS before such a 
+statement can be made?
+
+The portage devs need to commit to it. How do conflicts get resolved?
+\begin{verbatim}
+20:56 < dberkholz@> we were talking about this earlier today in here
+<20:57 < dberkholz@> to quickly summarize, EAPI 0 and portage need to agree. 
+                    there are some conflicts of opinion, and the question is 
+                    how do they get resolved?
+20:58 < dberkholz@> 17:24 <   zmedico > dberkholz: mainly these two:  
+                    http://bugs.gentoo.org/show_bug.cgi?id=222721  
+                    http://bugs.gentoo.org/show_bug.cgi?id=232990
+20:58 < dberkholz@> 17:25 <   zmedico > In both cases I consider something to 
+                    be negligible that  the pms folks do not
+
+20:59 <    Cardoe+> potentially creating a PMS editor post.
+21:00 <    Cardoe+> Put it in the hands of a third party
+21:00 <    Cardoe+> and if there's a conflict, let the council decide
+
+21:01 <    musikc > dberkholz, conflict in that some feel PMS is biased?
+
+21:07 <       spb > differences will be resolved by filing a bug, so what needs 
+                    to be sorted is what sort of escalation/mediation mechanism 
+                    there is
+\end{verbatim}
+
+We ran past the 1-hour mark, so this is pushed back to the list. It will 
+be on the next agenda in 2 weeks if it's not resolved by then.
diff --git a/decisions/summary-20080828.tex b/decisions/summary-20080828.tex
new file mode 100644
index 0000000..cce8d2d
--- /dev/null
+++ b/decisions/summary-20080828.tex
@@ -0,0 +1,89 @@
+
+\summary{2008}{8}{28}
+
+
+
+\agendaitem{Reactions to dev banned from freenode}
+\index{freenode}\index{irc!ban}
+
+Update: none. Assume lack of interest.
+
+
+\agendaitem{Moving meetings to a location we control}
+\index{council!meeting!location}
+
+Update: none. Assume lack of interest.
+
+
+\agendaitem{Favor irc.gentoo.org alias in docs, etc}
+\index{irc.gentoo.org}
+
+Update: Freenode acknowledgments page thanks people for doing this, so 
+the potential issue with confusion apparently isn't a large problem.
+
+Goal: Can we decide today?
+
+Decision: Update all our pointers to IRC to use irc.gentoo.org. (But 
+please mention FreeNode is our provider.)
+
+
+\agendaitem{Fired developers}
+\index{enforced retirement}\index{irc!ban}
+
+Why aren't fired developers banned from the channels where they
+displayed this behavior?
+
+Update: For banning from those channels: halcy0n, dertobi123 (on gentoo-dev)
+No opinions from the rest of us
+
+Goal: Get yes or no on banning from the same channels. If no, ask for 
+alternate suggestions if there are any. (Example: let devrel decide)
+
+Summary: halcy0n, dertobi123, lu_zero think fired devs should be banned 
+from the places where they behaved in the way that got them fired. 
+dberkholz and cardoe think that this should be handled by devrel and 
+council shouldn't set policy on it. halcy0n later agreed with letting 
+devrel address it, as did lu_zero and betelgeuse.
+
+
+\agendaitem{PMS as a draft standard of EAPI 0}
+\index{PMS}\index{EAPI!0}
+
+What changes are required before this is true?
+
+Update: The main thing that needs to get figured out is conflict 
+resolution.
+
+Idea: Ask portage devs \& PMS authors to develop a process that both 
+groups will respect, then present it to the council for approval. 
+Options include a "neutral" third party as PMS czar, having council 
+decide, just trying harder to come to agreement, deciding that e.g. 
+portage's choice always wins, random, etc.
+
+spb and ciaranm agree that a third party or council would work well. 
+Since such a third party would probably be better invested in actually 
+working on the spec, the council seems reasonable if PMS editors \& PM 
+developers can't work it out.
+
+\begin{verbatim}
+20:46 < dberkholz@> zmedico, ferringb, ciaranm, spb: so you'll all agree to 
+                    follow council decisions on conflicts you aren't able to 
+                    resolve otherwise?
+20:46 <   zmedico > dberkholz: I agree
+20:47 <  ferringb > dberkholz: either way, game to attempt something different- 
+                    what's in place doesn't particularly work imo
+20:47 <   ciaranm > dberkholz: so long as the council's prepared to follow 
+                    through with its resolutions
+20:49 <  ferringb > either way, council as arbitrator flies.
+\end{verbatim}
+
+Decision: Council will vote to resolve conflicts that the PMS editors 
+and PM developers weren't able to resolve.
+
+zmedico, ferringb \& ciaranm (developers of each PM) all agree that 
+having a written specification is worthwhile.
+
+Next meeting is Sept 11, and we request that everyone involved with PM 
+development or the spec email gentoo-dev about any issues with it. 
+Otherwise, it's likely to be approved as a draft standard.
+
diff --git a/decisions/summary-20080911.tex b/decisions/summary-20080911.tex
new file mode 100644
index 0000000..da8544f
--- /dev/null
+++ b/decisions/summary-20080911.tex
@@ -0,0 +1,39 @@
+
+\summary{2008}{9}{11}
+
+
+\agendaitem{Filling the empty slot}
+\index{council!members}
+
+Last time there was an empty slot, we voted on whether to fill the slot 
+with the next person from the original rankings. Let's do the same this 
+time. It's Cardoe.
+
+Goal: Vote whether to approve Cardoe for the empty council slot.
+
+Result: Cardoe is a new council member.
+
+
+\agendaitem{PMS as a draft standard of EAPI 0}
+\index{PMS}\index{EAPI!0}\index{EAPI!0!acceptance}
+
+Goal: Vote whether to approve PMS as a draft standard of EAPI 0.
+
+Requirements:
+\begin{itemize}
+ \item 
+ There needs to be a PMS lead who is a Gentoo dev [calchan].
+    Both cardoe \& antarus volunteered if this was needed.
+ \item
+ Document the conflict resolution process that we agreed upon last 
+    week [calchan].
+ \item
+ Document the patch acceptance process [halcy0n].
+ \item
+ Create a public mailing list so discussions and patches aren't lost on 
+    the pms-bugs alias [cardoe].
+\end{itemize}
+
+Result: PMS is a draft standard of EAPI 0, with acceptance conditional 
+upon resolution of the above 4 requirements. They should be resolved 
+within 2 weeks.
diff --git a/decisions/summary-20080925.tex b/decisions/summary-20080925.tex
new file mode 100644
index 0000000..136fa46
--- /dev/null
+++ b/decisions/summary-20080925.tex
@@ -0,0 +1,50 @@
+
+\summary{2008}{9}{25}
+
+
+\agendaitem{EAPI 2}
+\index{EAPI!2}\index{EAPI!2!approval}
+
+Goal: Vote on approval
+
+Requirements: 
+\begin{itemize}
+ \item
+ Put a generated copy (preferably HTML) in the PMS project webspace. 
+    People who want to refer to an EAPI=2 reference don't necessarily 
+    want to install all the dependencies to build it.
+ \item
+ Let's tag the git repository something like 
+    eapi-\$EAPI-approved-\$DATE.
+\end{itemize}
+
+Result: EAPI=2 is approved.
+
+
+\agendaitem{PROPERTIES in cache}
+\index{PROPERTIES}\index{metadata cache}
+
+Goal: Vote: Does council need to approve cache changes?
+
+Goal: Vote on approval
+
+Result: Since it's related to the EAPI, this should be another issue 
+that package-manager developers resolve amongst themselves and only 
+present to council if they can't agree.
+
+They agree on adding it to the cache as a value that package managers 
+can ignore, so it is.
+
+
+\agendaitem{PROPERTIES=interactive in ebuilds}
+
+Goal: Vote: Does council need to approve global-variable changes in 
+      ebuilds?
+
+Result: This is a retroactive, backwards-compatible EAPI change and thus 
+is handled the same as any other EAPI change -- it requires council 
+approval.
+
+Goal: Vote on approval
+
+Result: PROPERTIES=interactive is approved.
diff --git a/decisions/summary-20081023.tex b/decisions/summary-20081023.tex
new file mode 100644
index 0000000..98c35ea
--- /dev/null
+++ b/decisions/summary-20081023.tex
@@ -0,0 +1,46 @@
+
+\summary{2008}{10}{23}
+
+
+\agendaitem{Running through open bugs}
+
+
+Process: For each bug, come up with a concrete next step and who's going 
+to do it. If it's the council, a specific member should take 
+responsibility. The bug should be assigned to whoever needs to take the 
+next step and council@ should be in CC.
+
+Bugs handled:
+\begin{itemize}
+ \item 
+ \bug{185572}
+ \item
+ \bug{234705}
+ \item
+ \bug{234706}
+ \item
+ \bug{234708}
+ \item
+ \bug{234710}
+ \item
+ \bug{237381}
+\end{itemize}
+
+Bugs remaining:
+\begin{itemize}
+ \item 
+ \bug{234711}
+ \item
+ \bug{234713}
+ \item
+ \bug{234716}
+\end{itemize}
+
+
+\agendaitem{Meeting scheduling conflicts}
+\index{council!meeting!schedule}
+
+The 2nd meetings in November and December 
+conflict with holidays. If there are open bugs, we will hold them on the 
+3rd Thursday instead of the 4th Thursday; otherwise, they will be 
+canceled.
diff --git a/decisions/summary-20081113.tex b/decisions/summary-20081113.tex
new file mode 100644
index 0000000..27bee98
--- /dev/null
+++ b/decisions/summary-20081113.tex
@@ -0,0 +1,37 @@
+
+\summary{2008}{11}{13}
+
+
+\agendaitem{Open Bugs}
+
+\begin{itemize}
+ \item 
+ \bug{234706}:
+        Mark sent a proposal to gentoo-dev about this. No other discussion or
+	decision.
+ \item
+ \bug{234713}:
+        Conclusion:
+            This bug has been RESO LATER'ed pending concrete need and
+            consensus(GLEP 54 being the main one).
+ \item
+ \bug{185572}:
+        Conclusion:
+            Jorge(jmbsvicetto) will talk to other members of devrel about this
+            bug.
+ \item
+ \bug{234716}:
+        Conclusion:
+            Userrel is responsible for establishing these policies. Since each
+            developer is also a user at some point, these policies will apply
+            to developers as well as users.
+ \item
+ \bug{234711}:
+        Conclusion:
+            No decision. David Leverton commented that portage's current
+            method for identifying 'live' ebuilds was hackish, as it depends
+            on the list of inherited eclasses, which could change. Also, it
+	    was pointed out that some ebuilds use scm eclasses to check out
+	    specific revisions(mythtv). PROPERTIES=live was considered
+            as another option.
+\end{itemize}
diff --git a/decisions/summary-20081211.tex b/decisions/summary-20081211.tex
new file mode 100644
index 0000000..021ed78
--- /dev/null
+++ b/decisions/summary-20081211.tex
@@ -0,0 +1,39 @@
+
+\summary{2008}{12}{11}
+
+
+\agendaitem{Label profiles with EAPI for compatibility checks}
+\index{EAPI!in profiles}
+
+Should there be labels in the profiles telling package managers what
+        EAPI the profile uses. This proposal raised some concerns that
+        developers would modify current profiles and bump the EAPI which would
+        harm users' systems.
+
+Conclusion:
+	        Profile EAPI files are approved for use in gentoo-x86 profiles.
+            The file for use in profiles is 'eapi'. All current profiles
+            are EAPI="0" and only new profiles can be marked with the profile
+            EAPI markers. Any developer profiles can be marked with a new
+            EAPI.
+
+            
+\agendaitem{Retroactive EAPI change: Call ebuild functions from trusted working
+      directory}
+\index{EAPI!0}\index{EAPI!1}\index{EAPI!2}
+
+Donnie(dberkholz) commented that it may not be needed to add something
+        to EAPI=0 that is in all the Package Managers.
+
+        Conclusion:
+            Approved. This change applies to all current EAPIs(0,1,2).
+
+\agendaitem{Metadata variable for DEFINED_PHASES}
+\index{metadata cache}\index{DEFINED_PHASES}
+
+Should a metadata variable be added containing the list of all phases
+	defined in the ebuild or eclasses?
+
+        Conclusion:
+            Approved. Infra will do a full regen of the metadata cache once
+            portage has support for it.
diff --git a/decisions/summary-20090122.tex b/decisions/summary-20090122.tex
new file mode 100644
index 0000000..c04d392
--- /dev/null
+++ b/decisions/summary-20090122.tex
@@ -0,0 +1,9 @@
+
+\summary{2009}{1}{22}
+
+\index{GLEP!39}
+
+The council discussed potential changes to GLEP 39 and
+whether prep* functions are part of the public Portage API
+and as such would belong to EAPI. No votes were taken during
+the meeting.
diff --git a/decisions/summary-20090212.tex b/decisions/summary-20090212.tex
new file mode 100644
index 0000000..d266936
--- /dev/null
+++ b/decisions/summary-20090212.tex
@@ -0,0 +1,94 @@
+
+\summary{2009}{2}{12}
+
+\agendaitem{Should the council have a dedicated secretary?}
+\index{council!secretary}
+
+ Previously dberkholz fulfilled this roll, but he became busy.
+	Because fulfilling the secretary duties can distract from the
+	meeting, a dedicated, non-council member secretary is ideal.
+
+	Conclusion:
+	   tanderson is the new secretary. Logs and summary are to be
+	   posted on the -council mailing list. If no objections to it
+	   are raised in 1 day, it is posted to the council page and lists.
+
+\agendaitem{Council Elections}
+\index{council!elections}
+
+    	Should there be staggered elections every 6 months where half the
+	    council members stand for reelection?
+
+	Conclusion:
+	    Leave as-is, elections every 6 months is too cumbersome. Full elections
+        will be held once a year.
+
+       What happens if there aren't enough candidates nominated to fill all
+	    the council seats?
+
+	Conclusion:
+	    If the pseudo-candidate '_reopen_nominations' appears in 7th place
+	    or higher those candidates that rank above '_reopen_nominations'
+	    will be the current council. A second period of nominations will
+	    be opened for the remaining council seats. No third period of
+	    nominations will be opened in the event '_repoen_nominations'
+	    ranks higher than the candidates necessary to fill the council.
+
+
+\agendaitem{Prepalldocs}
+\index{prepalldocs}\index{EAPI!0}\index{EAPI!1}\index{EAPI!2}
+
+        Should 'prepalldocs' be allowed in current EAPIs?
+
+        Conclusion:
+            Prepalldocs is banned in current EAPIs(0,1,2). It should be
+            removed from ebuilds. Petteri Räty(Betelgeuse) will make QA
+            checks for repoman.
+
+\agendaitem{BASH version allowed in the tree}
+\index{bash!features in ebuilds}\index{PMS}
+
+        PMS states that ebuilds can only rely on BASH 3.0 features. However,
+        some code in gentoo-x86 uses BASH 3.1 features('+=' being the most
+        notable) and so is not in conformance with PMS. It was suggested that
+        BASH versions newer than 3.0 be allowed in a future EAPI. Ciaran
+        Mccreesh, however, commented that this would require GLEP 55 being
+        accepted so that a package manager would not have to source the ebuild
+        before knowing what BASH version it requires.
+
+        Conclusion:
+            No decision. Doug(Cardoe) will follow this up with
+            Tiziano(dev-zero) as a backup.
+
+
+\agendaitem{Open Bugs}
+
+\begin{itemize}
+ \item 
+ \bug{234711}:
+	    GLEP 54 solves two problems, version ordering and periodic reinstall
+	    of live packages. The Live Template proposal 
+\url{http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst} overlaps in that it 
+also
+	    allows for periodic reinstall of live packages. Luca(lu_zero)
+        maintains that Live Template provides proper version ordering, while
+        Ciaran(ciaranm) maintains that it does not. 
+
+        Conclusion:
+            No decision. The council cracked the whip on Luca(lu_zero) and
+            he's going to handle the issue.
+ \item
+ GLEP 55(.ebuild-\$eapi ebuild suffix)
+ 
+        Should .ebuild-\$eapi be approved? This ties in with "BASH version
+        allowed in the tree" issue mentioned above.
+
+        Conclusion:
+            No decision. Tiziano(dev-zero) will be handling this bug.
+
+ \item
+ Code of Conduct
+
+        Conclusion:
+            No decision. Donnie(dberkholz) will be handling this bug.
+\end{itemize}
diff --git a/decisions/summary-20090226.tex b/decisions/summary-20090226.tex
new file mode 100644
index 0000000..a7693e5
--- /dev/null
+++ b/decisions/summary-20090226.tex
@@ -0,0 +1,60 @@
+
+\summary{2009}{2}{26}
+
+
+\agendaitem{Open Council Spot}
+\index{council!members}
+
+Should leio fill the empty council spot?
+
+        Since Mark(halcy0n) resigned from the council there is an empty spot.
+        Since Mart Raudsepp(leio) is ranked next from the last election, he is
+        eligible to fill the spot.
+
+        Conclusion:
+            Mart Raudsepp is unanimously approved for the council.
+
+
+\agendaitem{GLEP 55}
+\index{GLEP!55}
+
+        There had been quite a bit of discussion on this topic recently.
+        Within hours of the council meeting new proposals were being proposed
+        and discussion was ongoing. 
+
+        Conclusion:
+            No decision as of yet. Ciaran Mccreesh(ciaranm) and Zac
+            Medico(zmedico) volunteered to benchmark the various proposals on
+            the package managers they maintain(paludis and portage
+            respectively. Petteri(Betelgeuse) will assist with the portage
+	    benchmarks. Tiziano(dev-zero) and Alec Warner(antarus) will write
+            up a comparison of the various proposals and their various
+            advantages and disadvantages within a week.
+
+\agendaitem{GLEP 54}
+\index{GLEP!54}
+
+        There had been some discussion on gentoo-dev since last meeting,
+        though no consensus or agreement had been reached(surprise!)
+
+        Conclusion:
+            Thomas Anderson(tanderson) and Luca Barbato(lu_zero) will write up
+            a comparison of the advantages and disadvantages of the two
+            proposals(-scm and _live). This will be completed within a week.
+
+            
+\agendaitem{Overlay Masking in Repositories}
+\index{package.unmask}\index{overlays}
+
+        Brian Harring(ferringb) asked for discussion for when overlays
+        attempted to unmask packages provided by the master 
+        repository(gentoo-x86). Because this is only available in portage
+        (it is contrary to PMS), Brian thought it should not be allowed.
+        
+        Numerous suggestions were made to the effect that if a standardized
+        set format was agreed upon for repositories and package.unmask was
+        allowed to contain sets, then this problem would be fixed.
+
+        Conclusion:
+            No decision, as only discussion was requested. Mart Raudsepp(leio)
+	    will follow up on this with discussion on gentoo-dev
diff --git a/decisions/summary-20090312.tex b/decisions/summary-20090312.tex
new file mode 100644
index 0000000..f1e3da5
--- /dev/null
+++ b/decisions/summary-20090312.tex
@@ -0,0 +1,131 @@
+
+\summary{2009}{3}{12}
+
+\agendaitem{EAPI-3 Proposals}
+\index{EAPI!3}
+
+Reference: \url{http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ}
+
+    Note: The following two proposals were discussed before it was realized
+    that there was not sufficient time to discuss all of them. At that point a
+    call for objections to any of the proposals found at above URL was asked 
+for,
+    and none were made. A full list of proposals for EAPI 3 follow.
+
+\begin{itemize}
+ \item 
+ New phase: pkg_pretend\index{pkg_pretend}
+ 
+        This phase is most useful for displaying conflicting USE flags at
+        dependency resolution time(pretend), though it has various other uses
+        so that errors about installing the package can be displayed before
+        installation of packages begin.
+
+        Conclusion:
+            Approved for the draft.
+ \item
+ USE dependencies\index{USE dependencies}\index{dependencies!use 
+flag}
+
+        This may be needed when one wishes to depend on a package with a
+        certain USE flag but if the USE flag is not present in that package
+        assume it is on or off(+ and - respectively).
+
+        Conclusion:
+            Approved for the draft.
+
+ \item
+ Multislot Dependency Specifications\index{multislot 
+dependencies}\index{dependencies!multislot}
+ 
+        This allows ebuils to tell the package manager that runtime
+        dependencies are not swappable(:1 installed at runtime can't be
+        removed even though :2 'satisfies' the dependency).
+
+ \item
+ PROPERTIES mandatory in cache\index{PROPERTIES}\index{metadata cache}
+ 
+        Some information provided by this variable is useful at --pretend
+        time(interactive packages). 
+
+ \item
+ DEFINED_PHASES mandatory in cache\index{DEFINED_PHASES}\index{metadata cache}
+ 
+        Same reasons as for PROPERTIES, but is also useful for determining
+        the phases a package provides with just the cache.
+
+ \item
+ Provide a default src_install prototype.\index{src_install}
+ 
+        Get rid of the need for the src_install functions with just `emake
+        install` in them. Some discussion is needed to clear up issues with a
+        DOCS variable for extra documentation and a list of docs to
+        automatically get installed.
+
+ \item
+ Provide a `docompress` function.\index{docompress}
+ 
+        This function serves as a replacement for prepalldocs. `docompress`
+        can optionally compress files in /usr/share/doc according to a set of
+        inclusion and exclusion lists.
+
+ \item
+ Provide a '-r' option to `dodoc`\index{dodoc}
+ 
+        Providing a way to put `dodoc` in recursive mode is widely accepted.
+
+ \item
+ Make `doins` preserve symlinks\index{doins}\index{symlinks}
+ 
+        This obsoletes the `cp -R` constructs frequently seen and is easy to
+        implement.
+
+ \item
+ Limit values in \$USE to those in 
+ \$IUSE.\index{USE}\index{IUSE}\index{USE_EXPAND}
+ 
+        Certain USE_EXPAND flags may be in USE even if they aren't
+        specifically set in IUSE. Eliminate this.
+\end{itemize}
+
+    Next Action:
+        The Council agreed to have portage implement as many of these as
+        possible in a month and then make that EAPI 3.
+
+        
+\agendaitem{GLEP 54}
+
+        Thomas(tanderson) sent out a comparison of \glep{54 }and the liveebuild 
+proposals.
+        Among those discussing GLEP 54 there was a general consensus that
+        there was nothing wrong with it as a first step to get correct
+        ordering. Luca(lu_zero) commented that all he was concerned about was
+        that there was not enough 'meat' to the GLEP.
+
+        Next Action:
+            Doug(Cardoe) and Luca(lu_zero) intend to write a
+            GLEP to handle the second part of the problem(making the revision
+            available to ebuilds/package manager/users.
+
+\agendaitem{GLEP 55}
+
+        Petteri, Zac, and Ciaran were supposed to benchmark the various
+        proposals and report back. Zac did not write the code for portage so
+        Petteri had nothing to report on this issue. Ciaran commented that
+        the solutions other than \glep{55} had a 50\% slowdown in the valid 
+cache
+        situation compared to GLEP55, but did not post the raw numbers or the
+	    patches used.
+
+        Next Action:
+            Zac needs to benchmark the proposals in portage.
+
+            
+\agendaitem{Open Floor}
+\index{KEYWORDS}
+
+
+Migration of KEYWORDS from ebuilds to profiles:
+  Ned Ludd(solar) brought this up, but it came up in the middle of agenda
+  items so was not talked about much. Some points were made that such a scheme
+  would require a git conversion, but nothing was agreed upon.