summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndreas K. Hüttel <dilfridge@gentoo.org>2017-04-01 18:34:41 +0200
committerAndreas K. Hüttel <dilfridge@gentoo.org>2017-04-01 18:34:41 +0200
commitc0138a4a1053a1283f3c41563da76f1991076efe (patch)
treea13e16a25144e414ad25b65ec0b29fd932a195b3 /decisions
parentIndex 2008/6 and 2008/7 (diff)
downloadcouncil-c0138a4a1053a1283f3c41563da76f1991076efe.tar.gz
council-c0138a4a1053a1283f3c41563da76f1991076efe.tar.bz2
council-c0138a4a1053a1283f3c41563da76f1991076efe.zip
Index 2008/7 to 2009/3
Diffstat (limited to 'decisions')
-rw-r--r--decisions/decisions.but12
-rw-r--r--decisions/decisions.bux12
-rw-r--r--decisions/decisions.tex21
-rw-r--r--decisions/summary-20080724.tex21
-rw-r--r--decisions/summary-20080814.tex165
-rw-r--r--decisions/summary-20080828.tex89
-rw-r--r--decisions/summary-20080911.tex39
-rw-r--r--decisions/summary-20080925.tex50
-rw-r--r--decisions/summary-20081023.tex46
-rw-r--r--decisions/summary-20081113.tex37
-rw-r--r--decisions/summary-20081211.tex39
-rw-r--r--decisions/summary-20090122.tex9
-rw-r--r--decisions/summary-20090212.tex94
-rw-r--r--decisions/summary-20090226.tex60
-rw-r--r--decisions/summary-20090312.tex131
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.