summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDonnie Berkholz <dberkholz@gentoo.org>2008-09-28 15:55:44 +0000
committerDonnie Berkholz <dberkholz@gentoo.org>2008-09-28 15:55:44 +0000
commit93270ef08194d477b41470e19a565701d2ecb1e3 (patch)
treebdb0c9134e319f7f094ac0dac09e7726c392b087
parentAdd the summary/log from July 24th (diff)
downloadcouncil-93270ef08194d477b41470e19a565701d2ecb1e3.tar.gz
council-93270ef08194d477b41470e19a565701d2ecb1e3.tar.bz2
council-93270ef08194d477b41470e19a565701d2ecb1e3.zip
Add the last 2 months of meetings. Also fix a typo in my nick from a summary I didn't add.
-rw-r--r--meeting-logs/20080814-summary.txt182
-rw-r--r--meeting-logs/20080814.txt430
-rw-r--r--meeting-logs/20080828-summary.txt91
-rw-r--r--meeting-logs/20080828.txt310
-rw-r--r--meeting-logs/20080911-summary.txt54
-rw-r--r--meeting-logs/20080911.txt317
-rw-r--r--meeting-logs/20080925-summary.txt53
-rw-r--r--meeting-logs/20080925.txt213
8 files changed, 1650 insertions, 0 deletions
diff --git a/meeting-logs/20080814-summary.txt b/meeting-logs/20080814-summary.txt
new file mode 100644
index 0000000..da4b531
--- /dev/null
+++ b/meeting-logs/20080814-summary.txt
@@ -0,0 +1,182 @@
+Roll call:
+betelgeuse here
+dberkholz here
+dertobi123 here
+flameeyes here [cardoe]
+halcy0n here
+jokey here
+lu_zero here
+
+
+Dates, or nothing to add:
+betelgeuse Monday
+dberkholz Monday
+dertobi123 Monday
+flameeyes Cardoe will ask
+halcy0n Monday
+jokey Today
+lu_zero ??? (Having sporadic power issues)
+
+
+Unplanned topics
+================
+
+All the council members should nominate default proxies.
+
+
+New topics
+==========
+
+Reactions to dev banned from 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.
+
+Q/C:
+
+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
+
+
+
+Moving meetings to a location we control
+----------------------------------------
+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.
+
+Q/C:
+
+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.
+
+
+We currently have 2 freenode group contacts: fmccor and rane.
+
+
+Favor irc.gentoo.org alias in docs, etc
+---------------------------------------
+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.
+
+Q/C:
+
+spb brought up a good point to think about.
+
+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.
+
+
+Why aren't fired developers banned from the channels where they
+displayed this behavior?
+---------------------------------------------------------------
+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.
+
+Q/C:
+
+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
+
+spb commented that the three fired devs were actually banned from
+#gentoo-dev for quite some time.
+
+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 :)
+
+
+PMS as a draft standard of 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?
+
+Q/C:
+
+The portage devs need to commit to it. How do conflicts get resolved?
+
+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
+
+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/meeting-logs/20080814.txt b/meeting-logs/20080814.txt
new file mode 100644
index 0000000..270cbf3
--- /dev/null
+++ b/meeting-logs/20080814.txt
@@ -0,0 +1,430 @@
+20:00 < dberkholz@> ok, it's time
+20:00 < dberkholz@> roll call please, who's here?
+20:00 <dertobi123@> <-
+20:00 <dertobi123@> heya btw
+20:00 -!- Irssi: #gentoo-council: Total of 72 nicks [6 ops, 0 halfops, 0 voices, 66 normal]
+20:01 < Cardoe > Cardoe for Flameeyes
+20:01 <Betelgeuse@> yes
+20:01 * Halcy0n is here
+20:01 < dberkholz@> jokey, lu_zero: are you here?
+20:03 * dberkhol waits
+20:03 < strites > hello
+20:03 < dberkholz@> jokey's been idle for almost 2 days, lu's around somewhere
+20:04 < Halcy0n@> I just IM'd jokey
+20:04 <NeddySeago > dberkholz, just go for it, you have a quorum
+20:04 < strites > I am here to say lu_zero's neighborhood got a black out
+20:04 < musikc > dberkholz, i was just talking to lu and he said he has the flu atm
+20:04 < musikc > wow, that sucks
+20:04 < rane > flu and blackout, what a day
+20:04 < dberkholz@> apparently he's doubly excused.
+20:04 < strites > just called me with cell
+20:04 < dberkholz@> that reminds me, we really need to get default proxies for everyone
+20:04 < strites > he told he'll be back asap ^^'
+20:05 <dertobi123@> can't get jokey on his mobile phone, so yeah ... seems he's away
+20:05 < rane > so two out
+20:05 < Halcy0n@> dertobi123: he just answered me on IM.
+20:05 < Halcy0n@> He's coming.
+20:05 <dertobi123@> ok
+20:06 * jokey looks up
+20:06 < jokey@> sorry for being late
+20:06 < dberkholz@> hopefully people had a chance to see what i suggested we should do during the meeting today
+20:07 < dberkholz@> if not, it's at the top of http://dev.gentoo.org/~dberkholz/20080814-agenda.txt
+20:07 * musikc hands lu_zero some juice and puts him the corner away from the others :-P
+20:08 < dberkholz@> to start off, i'd like to get commitments from everyone about when you'll reply on -dev to all the agenda topics (or -council for the CoC one)
+20:08 * jokey read the points already and formed an opinion
+20:08 < jokey@> next hour
+20:08 < jokey@> (given we have a meeting atm; was catching up on mails)
+20:08 < dberkholz@> i'm going to commit to monday, although i hope to get it done earlier
+20:09 -!- mode/#gentoo-council [+o lu_zero_] by ChanServ
+20:09 <dertobi123@> i can comment on the threads until end of the weekend
+20:09 < Halcy0n@> dberkholz: I'll respond to them all by the end of the weekend. I haven't read through everything yet since my DSL was out for 4 days.
+20:09 -!- lu_zero_ is now known as lu_zero
+20:09 < lu_zero@> uff
+20:09 < dberkholz@> lu_zero: 20:08 < dberkholz@> to start off, i'd like to get commitments from everyone about when you'll reply on -dev to all the agenda topics (or -council for the CoC one)
+20:09 < lu_zero@> I was missing thunderstorm....
+20:09 < lu_zero@> dberkholz I'll be flickering at best
+20:10 < Cardoe > dberkholz: I've obviously got to confer with Flameeyes on that. Not sure how much keyboard time he's got right now.
+20:10 < dberkholz@> Betelgeuse, dertobi123, jokey...
+20:10 < dberkholz@> jokey: did i understand correctly? you're going to send emails for all of them in the next hour?
+20:11 <dertobi123@> dberkholz: as i said, until the end of the weekend
+20:11 <Betelgeuse@> dberkholz: weekend is fine
+20:11 < jokey@> dberkholz: yeah, I read up on most topics so I should be able to send them soonish
+20:11 < dberkholz@> jokey: is soonish today?
+20:11 < jokey@> unless you have points to add that need other commenting
+20:12 < dberkholz@> yes, if there's ongoing discussion, we aren't setting a deadline on that
+20:12 < dberkholz@> just on getting your initial points out there
+20:13 < dberkholz@> lu_zero: please respond whenever you've got a reliable connection
+20:13 < dberkholz@> let's move on
+20:13 < lu_zero@> I'll try
+20:13 -!- dberkholz changed the topic of #gentoo-council to: Reactions to dev banned from freenode
+20:14 < dberkholz@> who's got a comment or question right now?
+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 > yes
+20:14 < musikc > ive spoken with the second dev actually
+20:15 <dertobi123@> who's the second one and when did that happen?
+20:15 < Halcy0n@> And is there any other informatino you can share with us in public, or is best to talk about this on council@?
+20:15 < musikc > he's still banned but i was able to speak to tomaw and kloeri who told me what to tell him. they said all info was in the ban message but the dev indicated otherwise. no real proving that
+20:16 < kloeri > I can confirm the info is in the ban message fwiw
+20:16 < kloeri > or was, whatever is the case - I don't know if they kline is expired or not
+20:16 < musikc > the guy said he'd done what he was told to do and was still waiting for some resolution
+20:17 < Cardoe > Halcy0n: council@ is a public ML.
+20:17 < Halcy0n@> Cardoe: not g-council, but the council alias
+20:17 < musikc > i last spoke to him on the 10th
+20:17 < Cardoe > Halcy0n: mm. my bad. you're right
+20:18 <KungFuJesu > ahoy
+20:18 < dberkholz@> alright
+20:18 < musikc > the guy is on another network if council wishes to speak with him
+20:18 < musikc > i can share info privately
+20:18 < Halcy0n@> I know who it is and can relay whatever I get from him to the rest of you.
+20:19 <KungFuJesu > who are the "dev banned from ferenode"?
+20:19 < Halcy0n@> I didn't connect dots :)
+20:19 <KungFuJesu > "freenode"*
+20:19 < dberkholz@> is there some particular reason we aren't mentioning whoever it is?
+20:19 <KungFuJesu > is this really a worthy discussion for the gentoo council?
+20:20 < antarus > it was requested they talk about it
+20:20 < Halcy0n@> dberkholz: it was ricmm. I don't see a problem with mentioning the name since the quit message clearly said he was klined.
+20:20 <KungFuJesu > I mean, it's just an IRC related issue, why aren't we discussing gentoo?
+20:20 < antarus > if they didn't want to discuss it they would just skip it
+20:20 <KungFuJesu > well, what was the reason he/she was banned?
+20:20 < dberkholz@> KungFuJesus: irc is a critical tool uses to do our job. if that tool is broken, it needs to be fixed.
+20:20 < Halcy0n@> KungFuJesus: this is a Gentoo related issue since its affecting one of our communication mediums for a dev.
+20:20 < dberkholz@> s/uses/gentoo uses/
+20:20 * fmccor has never herd of him.
+20:21 * KungFuJe hasn't either
+20:21 <KungFuJesu > heh, probably because he can't join our IRC
+20:21 < musikc > i dont think it matters who the dev is or if anyone heard of him fwiw, he's a dev all the same
+20:21 < Halcy0n@> dberkholz: I will talk to him and see if he wants to share why he was banned so we can discuss the specifics. If no one has anything else to add to this conversation point, I suggest we move on.
+20:22 * KungFuJe seconds that
+20:22 <dertobi123@> anyways, can we get the facts some of us have posted to council@, please?
+20:22 < Halcy0n@> KungFuJesus: please, unless you have something to add, can you refrain from commenting? Thank you
+20:22 < Halcy0n@> dertobi123: I will find out how he wants me to share the details and let you guys know either way.
+20:22 < tomaw > This issue was resolved on the day I was made aware of it. The dev in question is aware of that, and the reasons for the kline. I suggest you discuss with him to find out if he's willing to share.
+20:22 < musikc > dertobi123, i'll share the background that i have
+20:23 < dberkholz@> i don't really have more to add on this topic. more relevant to the next ones.
+20:23 <dertobi123@> Halcy0n, musikc: thanks :)
+20:23 < tomaw > Also, please /whois ricmm.
+20:23 <KungFuJesu > Halcy0n: Sorry, I just feel that there's not much to add as many details aren't being shared about
+20:23 < Halcy0n@> KungFuJesus: if you have nothing to add, you don't need to say anything then, so please, consider that.
+20:24 -!- dberkholz changed the topic of #gentoo-council to: Moving meetings to a location we control
+20:24 < antarus > Halcy0n: I think he gets the point ;p
+20:24 < Halcy0n@> antarus: I'm not sure he does ;)
+20:24 < lu_zero@> anyway
+20:24 < lu_zero@> back to the topic
+20:24 < tomaw > dberkholz: Could you just confirm my lines made it to the channel? Noone responded :)
+20:24 < dberkholz@> tomaw: yes
+20:24 < Halcy0n@> tomaw: yup, we saw.
+20:24 < tomaw > Thanks.
+20:24 < dberkholz@> tomaw: we haven't +q'd you yet. =)
+20:24 < jokey@> :D
+20:24 < spb > wouldn't make much difference if you had
+20:24 < markand > hi there
+20:25 < dberkholz@> anyone got a question/comment about the next topic?
+20:25 < musikc > dberkholz, all of these topics will be discussed on lists as well so voting can take place hopefully next mtg?
+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 <jmbsvicett > dberkholz: That issue should be discussed at the same time as having a gentoo irc network, imho
+20:26 * jokey is still not in favour of running an irc network
+20:26 <KungFuJesu > now that I agree on, if gentoo hosts the IRC server, these problems won't happen
+20:26 < Halcy0n@> dberkholz: I need to read all of the emails to understand what the motivation is for this, so I can't give any useful comments at this point in time.
+20:27 <KungFuJesu > honestly is there any reason to use freenode other than the fact it's easier than hosting it yourself?
+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:27 < musikc > motivation being that devs have asked for it?
+20:27 < Halcy0n@> musikc: I meant the reasoning behind asking for it.
+20:27 < musikc > been a bit of dialog on the lists for that
+20:27 < Halcy0n@> I haven't read it all yet. I have a backlog of emails I'm still sifting through :)
+20:27 < yngwin > also, the situation with the group contacts
+20:27 < antarus > dberkholz: I think our devs should be motivated to not get klined ;)
+20:27 < musikc > honestly, though wolf tried to calm it, i suspect the conversation started b/c of that incident
+20:28 < spb > all of which can be summed up with paranoia, conspiracy theories and general storm-in-a-teacup
+20:28 <KungFuJesu > antarus: you gotta point there, I wish I knew the reason he was klined
+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:28 < spb > yngwin: the situation is that gentoo has two active group contacts
+20:28 < Halcy0n@> spb: who are those 2? I thought it was musikc and rane?
+20:28 < musikc > spb, yes. i had to quit before that took place though
+20:28 < spb > ferris and rane
+20:29 < Halcy0n@> spb: oh, when was ferris added? I thought there was quite a backlog to getting GCs added?
+20:29 < spb > ferris was there all along
+20:29 < musikc > Halcy0n, this morning
+20:29 < spb > he was never properly removed
+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:29 < fmccor > Halcy0n, Turns out I have been all along, but didn't know I was still active.
+20:29 < spb > so when musikc left, he asked to be reactivated, as it were
+20:29 < Halcy0n@> spb: ah, okay.
+20:29 <KungFuJesu > Cardoe: how hard could it possibly be to run an irc server?
+20:30 < spb > ha. ha. ha.
+20:30 < Halcy0n@> Cardoe: I think us having to maintain it will be more of a headache.
+20:30 <KungFuJesu > I understand porting some of the bots may be a pain
+20:30 < spb > it's easy, if you have no users
+20:30 < Cardoe > Halcy0n: I'm in agreement with you on that.
+20:30 <dertobi123@> dito
+20:30 <KungFuJesu > does irc really eat that much bandwidth? Or are we talking about moderation issues?
+20:30 < Halcy0n@> But, I think these are all things that we should bring up on the list to figure out what is possible.
+20:31 < Halcy0n@> KungFuJesus: maintainence, legal issues, trolls, DoS attacks, etc
+20:31 < jokey@> indeed, let's discuss this there
+20:31 < Halcy0n@> There is a lot involved that we shouldn't waste the manpower on.
+20:31 <KungFuJesu > the DoS I can see as an issue, I don't know about legality, and trolls will troll
+20:31 < yngwin > but we could still move to oftc
+20:31 < Cardoe > Halcy0n: exactly
+20:31 <KungFuJesu > ban them when they're out of line, ignore them otherwise
+20:31 < Halcy0n@> yngwin: that is a possibility, but again, something we should discuss on the mailing lists to see if we do indeed want to move, how many people will do so.
+20:32 < Cardoe > We have other things to use manpower on, like developing a distribution.
+20:32 < yngwin > sure
+20:32 < Halcy0n@> I'd hate to see us get into a situation where half of our channels are on one networks, and half on the other.
+20:32 <jmbsvicett > Halcy0n: That has been raised in the mls
+20:32 < dberkholz@> KungFuJesus: you might want to bring up your questions on the gentoo-dev list once the meeting is over
+20:32 < Halcy0n@> jmbsvicetto: okay, good to know :)
+20:32 <Betelgeuse@> dberkholz: -project rather
+20:33 <KungFuJesu > Halcy0n: the division of networks I can see as a huge problem, as freenode is pretty much a wild west of channels
+20:33 < dberkholz@> suppose we should try to bounce that thread over
+20:33 < dberkholz@> next topic
+20:33 -!- dberkholz changed the topic of #gentoo-council to: Favor irc.gentoo.org alias in docs, etc
+20:33 <Betelgeuse@> +1
+20:33 < Halcy0n@> I agree with this, without even having to read anything on it
+20:33 < lu_zero@> fine with it
+20:34 < dberkholz@> in general, i like this idea regardless of the migration thing.
+20:34 <jmbsvicett > dberkholz: We already have the dns alias and should really use it instead of irc.freenode.org everywhere
+20:34 <dertobi123@> i guess we can easily vote on that, right?
+20:34 * KungFuJe agrees
+20:34 < dberkholz@> i like it for branding reasons
+20:34 < dberkholz@> kinda like irc.gnome.org actually goes to gimpnet
+20:34 < Halcy0n@> KungFuJesus: please, if you have something of substance to add to the conversation, do so, otherwise let us have our meeting.
+20:34 <KungFuJesu > I like it for consistency's sake, many distros follow the same trend
+20:34 < jokey@> ++
+20:35 < spb > experience from other networks shows that it becomes a pain in the arse for other random channels on that network, though
+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:36 < spb > less commonly
+20:37 < jokey@> I'd say at least one user every 3-4 days over in #gentoo-php
+20:37 < jokey@> so not that uncommon
+20:37 < Halcy0n@> spb: is this something that has caused a lot of pain for others already? And do you think if in our documentation we mention that Gentoo specific channels are #gentoo-* that would help?
+20:37 <Betelgeuse@> jokey: Quite common on #gentoo-java too even with the warnings all over the place.
+20:37 < spb > it happens quite a lot on other networks i oper/admin on
+20:38 < spb > and it wastes quite a lot of time talking completely at cross purposes before discovering what the person in question thinks he's on about
+20:38 <dleverton_ > People assuming that a #gentoo- channel is generic is pretty clearly a PEBKAC, whereas assuming that anything on irc.gentoo.org would be gentoo related seems a lot more reasonable.
+20:38 <KungFuJesu > I have seen some ubuntu-trolls come in from time to time
+20:38 < spb > plus, someone asking a generic java question in #gentoo-java is easily recognised and easily directed elsewhere
+20:39 < jilles > the 'independence' of a particular IRC network is rather good though
+20:39 < spb > someone asking about how to do something on a gentoo system in a red hat channel that he thinks is a gentoo channel, on the other hand, is apt to cause massive confusion
+20:39 < dberkholz@> alright, we've got some points worth thinking about here, so we might want to hold off on an instant vote and finish it up on-list
+20:39 < Halcy0n@> dberkholz: I agree.
+20:40 < Halcy0n@> spb: thanks for the insight.
+20:40 < dberkholz@> thanks for bringing that up, spb
+20:40 < jokey@> dberkholz++
+20:40 <KungFuJesu > spb: I admit to doing this myself
+20:40 < dberkholz@> anything else new on this topic?
+20:40 <KungFuJesu > let's try to consider the IRC client, though. If one isn't aware of what channel they're typing into this same problem will happen anyway
+20:41 <Betelgeuse@> KungFuJesus: ?
+20:41 < dberkholz@> are there many popular irc clients that don't display the channel?
+20:41 < dberkholz@> that seems a bit hard for me to grasp
+20:41 <KungFuJesu > they display it, but it's easy to forget it's there sometimes
+20:41 < blackace > uhh, we're still talking about this? if someone is too stupid to realize where they are, they're too stupid no matter what we do
+20:41 <Betelgeuse@> blackace: yeah exactly
+20:41 <KungFuJesu > I'm using irssi, and maybe I'm just stupid, but I've done it
+20:41 < blackace > we should do what is best for Gentoo, not what is best for stupid people
+20:42 < Halcy0n@> blackace: I agree, but its worth considering the impact we'll have on other users of the network.
+20:42 <Betelgeuse@> dberkholz: Some people come around to IRC via some Java applets for example and don't really know what they are doing.
+20:43 <Betelgeuse@> But that's not the point here.
+20:43 < spb > blackace: sometimes what's best for gentoo is not pissing off the people who host services for you
+20:43 < blackace > Halcy0n: I don't see what impact we'll have, if a gentoo user joins ##php and asks a php question, it's probably still on-topic
+20:43 < dberkholz@> yeah, i don't really think any of this part is relevant
+20:43 <KungFuJesu > spb: would freenode be angry if we left their network?
+20:43 < blackace > spb: I don't really care
+20:43 < dberkholz@> if people type iwthout reading, then they do
+20:43 < spb > so i noticed
+20:43 < dberkholz@> without*
+20:43 < Halcy0n@> (random aside, its now pouring here, so if I disconnect, I lost power)
+20:43 < dberkholz@> so let's move on to the next topic
+20:43 -!- dberkholz changed the topic of #gentoo-council to: Why aren't fired developers banned from the channels where they displayed this behavior?
+20:44 < dberkholz@> anyone have a question/comment/response?
+20:44 < blackace > isn't that kind of up to the individual channel owners except in the case of #gentoo-dev?
+20:44 <KungFuJesu > sorry for my ignorance, but what behavior?
+20:44 < dberkholz@> KungFuJesus: if you don't have the context for this discussion, you might want to sit it out
+20:44 < blackace > KungFuJesus: the behavior that got them fired?
+20:44 < musikc > blackace, what about the common ones like #-dev? would that be different?
+20:44 <KungFuJesu > oh I see
+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 < blackace > musikc: err, I said, except for -dev :)
+20:45 <dleverton_ > *weren't
+20:45 < musikc > hehe, sorry blackace
+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 < musikc > ive been asked about specific devs
+20:45 * dleverto will read it again.
+20:45 < dberkholz@> what i understood was that we should ban them from the same communication channel
+20:45 < Halcy0n@> dberkholz: I will post my feedback on the thread.
+20:46 < spb > can i just point out at this point that the majority of "evidence" presented against the three of us that were removed came from #gentoo-dev
+20:46 < dberkholz@> and allow other ones where they handled themselves differently
+20:46 < spb > and that we were banned from there for quite some time
+20:46 < musikc > ok, from a devrel perspective it is not a right for retired devs to automatically get voice in #-dev
+20:46 < blackace > musikc: the only issue I see with -dev is that since they're not banned they rely on another dev voicing them and two devs could get into a +v/-v war over it
+20:46 <dleverton_ > I asked who he was referring to, aballier said "nowhere have I seen any accusation", and yngwin said he agreed (and certainly didn't ganswer my question directly).
+20:47 < musikc > blackace, thats a recent freenode limitation
+20:47 <dleverton_ > If there is no accusation, that presumably no-one is being accused.
+20:47 < musikc > blackace, and maybe a bot could take care of that
+20:47 < yngwin > dleverton_: because i dont want to talk about specific cases, but about policy
+20:47 < antarus > I used to get annoyed when spb trolled #gentoo-dev often
+20:47 < blackace > musikc: yeah, there are more than a few ways to skin that cat :)
+20:47 <KungFuJesu > if they're fired, I can see why they shouldn't be able to speak in the *-dev channels, however if they quit on their own volition, there is a sense of welcomed experience for a veteran developer to come back and give input
+20:47 < antarus > but I find now that I'm not on irc as much i don't care
+20:47 <dertobi123@> i think this topic belongs to the CoC discussion as its a part of that discussion
+20:48 < fmccor > Isn't there already a policy question on this sort of thing floating around?
+20:48 < musikc > fmccor, the policy discussion i think you refer to is the extent of CoC enforcement?
+20:49 < blackace > if the CoC is violated, wouldn't they have already been banned prior to being fired?
+20:49 < kloeri > musikc: I don't get your comment about a recent freenode limitation - you can ban and unvoice people if you like just as you've always been able to
+20:49 <jmbsvicett > dertobi123: I think you'll be restricting it much if you put it under CoC - it's a larger issue
+20:49 <dleverton_ > yngwin: so it's purely a hypothetical question, then?
+20:49 < fmccor > I think so. As I said, I'm not even sure what that iw about anymore.
+20:49 < musikc > kloeri, tomaw knows what i refer to, long conversation about it
+20:49 < Halcy0n@> kloeri: she means the -1 access level to automatically remove ops/voice.
+20:49 <jmbsvicett > kloeri: mode -1, iirc
+20:49 * musikc nods and hands cookies to Halcy0n and jmbsvicetto
+20:49 < blackace > mind readers!
+20:50 < spb > there is a general principle on which almost all IRC-based software is designed
+20:50 < spb > and that is that if you don't trust someone, you don't give them operator access
+20:50 < blackace > spb: which probably has nothing to do with this meeting
+20:50 < spb > which makes access level -1 redundant
+20:50 < musikc > blackace ++
+20:50 < kloeri > there's a rather easy solution to that.. don't give +o to people that can't follow gentoo decisions and keeps removing bans and voicing people who're not supposed to be voiced
+20:50 < spb > blackace: quite true, but then nor did the comment to which i was responding
+20:51 < Halcy0n@> dberkholz: I think we aren't getting much here, so I suggest we bring this to the ML to discuss any points people want to bring up.
+20:51 < dberkholz@> does anyone have a new question or comment that's directly related to the topic?
+20:51 < tomaw > Is the council interested in the autodevoice feature or is this rambling off topic?
+20:51 < Cardoe > ok wrangling this back on topic...
+20:51 < tomaw > If you are then I have a simple explanation. If not, I won't bother.
+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 -!- mode/#gentoo-council [+v Cardoe] by Halcy0n
+20:51 <jmbsvicett > tomaw: As long as we stick to freenode, -1 is something that interests us
+20:51 < Cardoe+> This needs to be kicked back to the list.
+20:52 < Halcy0n@> Cardoe: agreed.
+20:52 < tomaw > Well, I can tell you that the feature isn't present on OFTC either ;)
+20:52 < Cardoe+> It probably even belongs in devrel's level.
+20:52 < blackace > OFTC isn't our only option
+20:52 < tomaw > True, but it is one, hence me mentioning it.
+20:52 < Cardoe+> Standardize a policy for what happens to voluntarily retired devs and forcibly retired devs.
+20:52 < Halcy0n@> This is all a bit off topic, so if we could please go back to the topic at hand.
+20:52 < blackace > sorry :)
+20:52 < tomaw > Halcy0n: sure, sorry.
+20:53 < dberkholz@> since nobody's adding anything on the topic, let's move on
+20:53 < dberkholz@> feel free to discuss the other stuff on -dev or wherever you like besides right here and right now =)
+20:53 < Cardoe+> Can we actually tweak it?
+20:53 < Cardoe+> the council direct devrel to come up with a proposed solution/policy
+20:53 < Cardoe+> and move along
+20:53 < musikc > Cardoe, im happy to do so
+20:54 < jokey@> deal then ;)
+20:54 < musikc > dberkholz, declare it an action item and im there :)
+20:54 <dertobi123@> heh
+20:54 < dberkholz@> i don't agree with having a written policy for everything
+20:54 < dberkholz@> Cardoe: i added your point to the summary, i'd like to discuss it more
+20:55 < musikc > dberkholz, your call. happy to assist by doing work or by just stating current process and devrel stance :)
+20:55 < dberkholz@> (outside the meeting)
+20:56 < musikc > sold!
+20:56 < dberkholz@> if there aren't any other questions/suggestions, let's move on
+20:56 < musikc > hehe
+20:56 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0
+20:56 < dberkholz@> we were talking about this earlier today in here
+20:56 < Cardoe+> I'd say we're pretty close on this
+20:57 < musikc > dberkholz, i propose taking it to the list due to discussion from prior to this meeting
+20:57 < Cardoe+> save for the PMS guys feel one way and ${package_manager} feels another way
+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:57 < ciaranm > specific examples please?
+20:57 < spb > ciaranm: --jobs breaking invariancy was one example given
+20:58 < Cardoe+> my proposal is open a specific bug and have a specific bug at hand and let the council decide which way as far as conflict resolution.
+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:58 < ciaranm > ah. well, the way portage does --jobs is broken. so pms is right there and someone needs to make zmedico fix portage
+20:58 <jmbsvicett > dberkholz: There must also be a way for future updates to the doc to take input from all PMs and not to be at the discretion of the current people behind PMS
+20:58 < ciaranm > portage is breaking existing stuff in the tree, so portage is in the wrong there
+20:58 < musikc > jmbsvicetto, makes sense
+20:58 < ciaranm > jmbsvicetto: examples of where we've rejected input please?
+20:59 < zmedico > ciaranm: I haven't seen any evidence to support you claims
+20:59 < Cardoe+> potentially creating a PMS editor post.
+20:59 < ciaranm > zmedico: it's on the bug
+20:59 < Calchan > ciaranm, broken from whose point of view besides yours ?
+20:59 < Cardoe+> That person can not be a developer on ANY package manager
+20:59 < musikc > i liked Halcy0n's idea about some kind of third party work on it
+20:59 < zmedico > ciaranm: not good enough
+20:59 < ciaranm > Calchan: objectively broken
+20:59 < zmedico > subjectively
+20:59 < ciaranm > Cardoe: examples of where the current editors aren't doing well enough?
+20:59 < Cardoe+> Halcy0n: You and I discussed this long ago
+20:59 < musikc > dberkholz, definitely sounds like a take it to the list item
+20:59 < Halcy0n@> Cardoe: the mediation thing? Yes, and I brought it up again earlier :)
+20:59 < ciaranm > zmedico: no no. causing system breakage is not subjective.
+20:59 < Cardoe+> ciaranm: no situation where the current editors are not
+21:00 < dberkholz@> what we're trying to do here is not have a discussion, but figure out where the conflicts and questions are
+21:00 < Cardoe+> ciaranm: It's just the logical solution.
+21:00 < Halcy0n@> dberkholz: I think the mailing list would be best to get all of these things straightened out.
+21:00 < Cardoe+> Put it in the hands of a third party
+21:00 < zmedico > ciaranm: you don't have enough evidence to show it's not neglible
+21:00 < antarus > indeed too much talking here ;p
+21:00 < Cardoe+> and if there's a conflict, let the council decide
+21:00 < spb > it's the logical solution based on an irrational set of premises
+21:00 < Cardoe+> however there should be an explicit bug.
+21:00 < ciaranm > Cardoe: i'd say the logical solution is using what's available, given limited manpower...
+21:00 < ciaranm > zmedico: two different packages running eselect opengl to save and restore in pkg_*. b0rk!
+21:00 < Cardoe+> fine. I'll volunteer to be the PMS editor
+21:00 < Cardoe+> everyone can submit patches to me
+21:01 < ciaranm > Cardoe: what are your qualifications?
+21:01 < musikc > dberkholz, conflict in that some feel PMS is biased?
+21:01 < Cardoe+> and when there's a specific conflict
+21:01 < ciaranm > musikc: specific examples of bias please
+21:01 < zmedico > ciaranm: I've never seen it happen
+21:01 < Cardoe+> I'll create a specific bug and ask the council to decide
+21:01 < ciaranm > zmedico: so? it can happen
+21:01 <jmbsvicett > ciaranm: What are *your* qualifications?
+21:01 < ciaranm > jmbsvicetto: i wrote the only independent implementation of EAPIs 0 and 1
+21:01 <Betelgeuse@> Well we shouldn't be changing EAPI 0 stuff in the first place. We should be creating new EAPIs.
+21:01 < ciaranm > jmbsvicetto: and i wrote more than half of PMS
+21:01 < musikc > ciaranm, he asked what the conflict was and i was commenting to conversations you were not present for prior to meeting hence my previous statement of a 'take it to the list' item for further discussion
+21:01 <KungFuJesu > later
+21:01 <jmbsvicett > ciaranm: really?
+21:01 < zmedico > ciaranm: I doubt it
+21:02 < ciaranm > zmedico: explain how portage prevents the scenario i described frmo happening
+21:02 < ciaranm > jmbsvicetto: really to which one?
+21:02 <jmbsvicett > ciaranm: To writting the "only independent" implementation
+21:02 < zmedico > ciaranm: explain an upgrade scenario where it will happen
+21:02 < antarus > ciaranm: I thinnk the answer is 'it does not' and 'he does not care'
+21:02 < Halcy0n@> dberkholz: are we done? :)
+21:02 < dberkholz@> does anyone have a new point here?
+21:02 < antarus > just +m the channel and get on with it ;)
+21:02 < spb > or rather, does the council have an answer to the question that i posed?
+21:02 < dberkholz@> all i'm seeing is the same argument going back and forth
+21:03 < lu_zero@> sigh
+21:03 < ciaranm > jmbsvicetto: pkgcore uses a lot of portage stuff, which is why it doesn't find a lot of the issues paludis does
+21:03 < ciaranm > zmedico: two packages do the save / restore stuff in pkg_*. portage parallelises them. splat.
+21:03 < dberkholz@> ciaranm, zmedico: could you discuss this somewhere else, please?
+21:03 < Cardoe+> seriously. We need to hash out a proper channel
+21:04 < jokey@> yep
+21:04 < ciaranm > dberkholz: i'd like the council to discuss it, since zmedico is being deliberately ignorant
+21:04 < ciaranm > in that he knows it's possible for breakage to happen, and he chooses to say "i haven't seen it so it doesn't exist"
+21:04 < Cardoe+> dberkholz: we can legitimately discuss the two bugs that zmedico and ciaranm have pointed out.
+21:04 < Halcy0n@> We've hit our one hour mark, so I'd like to slate this for our next meeting. I have to call into a meeting for work right now.
+21:04 < dberkholz@> Cardoe: on the list...
+21:05 < jokey@> Halcy0n: ++
+21:05 <Betelgeuse@> spb: Doesn't look like it.
+21:05 < spb > somehow i'm not overly surprised
+21:05 < dberkholz@> ok.
+21:05 < Cardoe+> spb: what was the question?
+21:05 < ciaranm > does the current council even still consider pms a priority?
+21:05 < dberkholz@> It should be treated as a draft standard, and any deviations from it
+21:05 < dberkholz@> found in the gentoo tree or package managers should have a bug filed
+21:05 < dberkholz@> against either the deviator or PMS to resolve the differences.
+21:05 < dberkholz@> Alternatively, what (specific) changes are required to PMS before such a
+21:05 < dberkholz@> statement can be made?
+21:06 < dberkholz@> ok.
+21:06 <Betelgeuse@> In general I agree that we should push for this to get things forward.
+21:06 < dberkholz@> as Halcy0n said, we've hit the one-hour mark
+21:06 < Cardoe+> I'd vote for that statement to be true as long as we can specify the method to resolve differences.
+21:06 < Halcy0n@> spb: with everything going back and forth, I can't make a decision on it until we figure out how differences will be resolved and/or handled.
+21:06 < dberkholz@> so we'll push this to the list, and bring it up again in 2 weeks if we haven't gotten it resolved on-list
+21:07 < Halcy0n@> Which seems to need further discussion.
+21:07 <Betelgeuse@> Cardoe: I would just put the council actively involved.
+21:07 < lu_zero@> fine
+21:07 < dberkholz@> i look forward to seeing everyone's responses to all these topics on the list by monday
+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
+21:07 <Betelgeuse@> At least something technical to talk about instead of the project stuff.
+21:07 <jmbsvicett > spb: I think there's a bit more to discuss than that
+21:08 < ciaranm > jmbsvicetto: specifically what?
+21:08 < Halcy0n@> dberkholz: thanks for chairing.
+21:08 < dberkholz@> feel free to continue discussion, although this meeting is over
+21:08 <jmbsvicett > specifically that the document doesn't reflect what the authors want to reflect instead of what is the reality or what people around gentoo want it to reflect
+21:08 < dberkholz@> and please post anything important to the list
diff --git a/meeting-logs/20080828-summary.txt b/meeting-logs/20080828-summary.txt
new file mode 100644
index 0000000..2bd1887
--- /dev/null
+++ b/meeting-logs/20080828-summary.txt
@@ -0,0 +1,91 @@
+Roll call
+=========
+betelgeuse here
+dberkholz here
+dertobi123 here
+flameeyes here [cardoe]
+halcy0n here
+jokey here
+lu_zero here
+
+
+Old topics
+==========
+
+Reactions to dev banned from freenode
+-------------------------------------
+Update: none. Assume lack of interest.
+
+
+Moving meetings to a location we control
+----------------------------------------
+Update: none. Assume lack of interest.
+
+
+Favor irc.gentoo.org alias in docs, etc
+---------------------------------------
+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.)
+
+
+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.
+
+
+PMS as a draft standard of 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.
+
+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.
+
+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/meeting-logs/20080828.txt b/meeting-logs/20080828.txt
new file mode 100644
index 0000000..b731ee8
--- /dev/null
+++ b/meeting-logs/20080828.txt
@@ -0,0 +1,310 @@
+19:56 < dberkholz@> are folks around?
+19:56 < lu_zero@> \o/
+19:56 < dberkholz@> if it starts to get out of hand like last time, i'm gonna have to +m it.
+19:56 -!- Irssi: #gentoo-council: Total of 59 nicks [6 ops, 0 halfops, 0 voices, 53 normal]
+19:58 <Betelgeuse@> dberkholz: yes
+20:00 * dertobi1 is around
+20:00 < dberkholz@> ok, it's 2000
+20:00 -!- mode/#gentoo-council [+v Cardoe] by dberkholz
+20:01 * jokey looks up
+20:01 < dberkholz@> Halcy0n: ping
+20:02 < dberkholz@> we've got 6, let's get started. hopefully he shows up in the next few min
+20:02 < Halcy0n@> Present :)
+20:02 < dberkholz@> oops, never actually saw Cardoe respond
+20:03 < Cardoe+> I'm here
+20:03 < dberkholz@> ok
+20:03 < dberkholz@> agenda's in /topic if anyone hasn't had a chance to look it over
+20:03 < Cardoe+> Was just zoned out staring at the wall waiting for the meeting to begin :-D
+20:03 < dberkholz@> sorry for the delay in getting it out, i've got a lot on my mind
+20:04 < dberkholz@> (new baby showing up in a few days)
+20:04 < jokey@> congrats ;)
+20:04 -!- dberkholz changed the topic of #gentoo-council to: Favor irc.gentoo.org alias in docs, etc
+20:04 < lu_zero@> I think we are all fine with this
+20:04 < dberkholz@> so, folks on -dev pointed out that apparently freenode folks like when other domains point to them
+20:04 < lu_zero@> (congrats btw)
+20:04 < Halcy0n@> congrats :)
+20:04 <Betelgeuse@> dberkholz: congrulations/condolences
+20:05 < dberkholz@> heh, that's more accurate, no doubt.
+20:05 < Halcy0n@> I think we are ready to vote on this one.
+20:05 <Betelgeuse@> yes
+20:05 < dberkholz@> yes
+20:05 <Betelgeuse@> and yes
+20:05 <dertobi123@> yes
+20:05 < Cardoe+> I was ready last week.. ;)
+20:05 < Cardoe+> yes
+20:06 < jokey@> yes
+20:06 < jokey@> :D
+20:06 < Halcy0n@> yes
+20:06 < dberkholz@> cool
+20:06 -!- dberkholz changed the topic of #gentoo-council to: Why aren't fired developers banned from the channels where they displayed this behavior?
+20:07 <Betelgeuse@> I don't think banning is necessary if the behaviour in question was misusage of power.
+20:07 < dberkholz@> Halcy0n & dertobi123 already replied on -dev saying they think fired devs should be banned from that place
+20:07 < jokey@> same here
+20:07 < lu_zero@> +1
+20:07 < dberkholz@> my opinion is that devrel should decide
+20:07 < spb > the obvious answer is that they should be banned from any place where they've shown behaviour that would get any normal person banned
+20:08 <Betelgeuse@> I agree with spb.
+20:08 < dberkholz@> and if anything, we should just say devrel (or whoever's in charge of a certain place) has the right to do so
+20:08 < spb > and, therefore, not from any place where they haven't
+20:08 < Halcy0n@> spb: I think that's what I was trying to say, if I didn't word it in that exact way. :)
+20:08 < Cardoe+> dberkholz: as I suggested last week. empower devrel to make the proper decision and to create a policy on this.
+20:08 < spb > given that, i don't really see what being fired has to do with it
+20:09 < Calchan > I don't agree, they've shown inapropriate behavior, the place doens't matter, they could have done it anywhere
+20:09 < dberkholz@> that's beyond the scope of this topic, which is a bit more focused
+20:09 <dleverton_ > So now we're punishing people for what they "could" have done?
+20:10 * musikc|l is back
+20:11 <musikc|lap > "saying they think fired devs should be banned from that place" +1
+20:11 < Cardoe+> dberkholz: so what's the formal question asked of the council.. cause why isn't something for the council to answer since the council doesn't do the banning
+20:11 < Cardoe+> devrel does
+20:11 <musikc|lap > Calchan, do you think a fired dev should be banned from all channels? not sure i understand and want to clarify
+20:12 < Cardoe+> so the question should be why don't we empower devrel to establish a policy and enforce it
+20:12 < rane > devrel or userrel?
+20:12 < Calchan > musikc|laptop, the problem is the behavior, not the channel
+20:12 <Betelgeuse@> Cardoe: I don't think we need to be handling fired devs any different from other users.
+20:12 < antarus > Calchan: I disagree; the day the coucil says I have to ban a user from a channel I own is the day I resign
+20:12 <musikc|lap > Calchan, that makes sense but no one team has the authority unless council opts to grant it to control every #gentoo-*
+20:13 <Betelgeuse@> If our policies on banning users aren't clear then they can be improved.
+20:13 < Cardoe+> Betelgeuse: and that policy is to have userrel have a policy and enforce it
+20:13 < antarus > s/says/forces/
+20:13 < antarus > they are free to make a compelling argument for a ban of course ;)
+20:13 <musikc|lap > Cardoe, i think it depends actually
+20:14 <musikc|lap > if the dev is being fired for a certain behavior such as inappropriate channel behavior, perhaps devrel is being asked why we dont automatically remove them from that channel, or as Calchan points out all channels.
+20:14 <musikc|lap > if its a former dev who later exhibits that behavior it's totally user rel
+20:14 < spb > the most obvious response to which is that it's up to the channel owners who they allow in their channels
+20:15 <musikc|lap > spb, see my previous comment about how no one team has that authority currently
+20:15 < ciaranm > in the same way that a gentoo developer spamming one irc channel is removed from all of freenode, you mean?
+20:15 <dleverton_ > musikc|laptop: the authority to let channel owners decide how to run their channels?
+20:15 < dberkholz@> this clearly has the potential to run forever, so let's set a 15-minute time limit on discussion here.
+20:15 < dberkholz@> starting now
+20:15 <musikc|lap > dleverton_, im merely stating that no one team has absolute authority in every channel
+20:15 < Calchan > antarus, the question is should you own an official gentoo channel or should gentoo own it ?
+20:16 <musikc|lap > dberkholz, can you define if the question pertains to only certain channels or all?
+20:16 < antarus > Calchan: perhaps gentoo should trust its developers to make good choices ;)
+20:16 <musikc|lap > Calchan, Gentoo owns it. when someone leaves the project the channel is handed over to another person, not left with ownership to the previous
+20:16 < spb > Calchan: and gentoo's policy has long stated that individual teams and/or developers own and run their channels
+20:17 < dberkholz@> musikc|laptop: the question is pretty specific. it's just banning from the place where they showed that kind of behavior
+20:17 <musikc|lap > dberkholz, then perhaps we should stick to just that question for now.
+20:17 < spb > dberkholz: in which case it's up to the channel owner to decide what sort of behaviour warrants a ban from that channel
+20:17 < spb > that seems fairly obvious to me
+20:17 <musikc|lap > i agree that if the person is removed from gentoo for such behavior that we should remove them from that channel
+20:18 < dberkholz@> each irc channel isn't a separate organization, though. we're all part of gentoo
+20:18 <musikc|lap > dberkholz, so you want to change the question to apply to all channels then?
+20:18 * blackace doesn't see the issue, if they get fired for misbehaving somewhere they were probably removed from that somewhere before being fired, if they then misbehave somewhere else as a user, ban them from there, and so on...
+20:18 < spb > and each channel is part of freenode, but we know enough to leave management of them to the channel owner
+20:18 < dberkholz@> i'm still trying to figure out the best way to go. i'm just making some points
+20:18 < rane > it's unrealistic to ban a person in all #gentoo-* channels
+20:18 <dleverton_ > Can we define what exactly we mean by "channel"? IRC, or more general?
+20:19 <musikc|lap > spb, a channel owner owns the channel as granted by Gentoo. otherwise it wouldnt be an official Gentoo channel
+20:19 < dberkholz@> more general for the whole topic -- a mailing list, the forums, etc
+20:20 <jmbsvicett > One point that has been raised is whether the council want to treat ex-devs differently from other users
+20:20 <jmbsvicett > If not, devrel doesn't deal with users.
+20:20 < jokey@> the only difference is that they get auto+v in #-dev afaik
+20:20 <musikc|lap > jmbsvicetto, i think the topic is upon removing them, not later. if it's later then its definitely not a dev rel issue and they should be treated as any user
+20:21 <musikc|lap > jokey, devrel doesnt grant +V to everyone, first they must ask and second it must be approved
+20:21 <jmbsvicett > musikc|laptop: I understand. Another question is if we're talking about #gentoo-dev, #gentoo or specific projects channels
+20:21 <dertobi123@> dberkholz: i disagree, if this topic would be about lists, forums, #gentoo-* we're back at the "total ban from gentoo" discussion
+20:22 < dberkholz@> dertobi123: not really. it's just saying that banning from a specific place applies equally to a single irc channel or a single mailing list.
+20:22 <musikc|lap > jmbsvicetto, the question per dberkholz's explanation is for just #-dev but the discussion could include thoughts on all mediums and channels
+20:22 < dberkholz@> we're not at all addressing right now whether people should be additionally banned from other places
+20:23 <musikc|lap > council, so to the question at hand, only dberkholz and Halcy0n have shared their views. any others?
+20:23 < dberkholz@> dertobi123 did too, on list. =)
+20:23 <dertobi123@> yep
+20:24 < lu_zero@> and I just said that I agreed
+20:24 < Cardoe+> my opinion is that it should be up to devrel
+20:24 <dertobi123@> it's a logical step to ban someone from a place where he showed misbehaviour
+20:24 * musikc|l agrees
+20:24 <jmbsvicett > musikc|laptop: If it's #gentoo-dev, then I think it's up to devrel
+20:24 <dertobi123@> i don't see what needs to be discussed there besides the way of the how this if enforced
+20:25 <musikc|lap > dertobi123, how about enforced upon removal?
+20:25 < Halcy0n@> I'm fine with just saying that this is up to devrel to decide on their policy and if someone wishes to question that policy, we address it at that point in time.
+20:26 <musikc|lap > Halcy0n, im ok with that. however id hope if someone wants to discuss a devrel policy they discuss it with ... you know... devrel first
+20:26 <dertobi123@> musikc|laptop: ack. it should be part of the retirement process from my pov (except when the person in question already has been banned from this places)
+20:26 < jokey@> ++
+20:26 <musikc|lap > dertobi123, +1
+20:27 < Cardoe+> seems like there's a reasonable consensus.... now on to technical things..
+20:28 <musikc|lap > agreed, ill work with rane and jmbsvicetto to hammer out any details from a devrel pov and we'll run it through the rest of devrel for feedback
+20:28 < dberkholz@> we haven't gotten agreement from a council majority on that
+20:28 < dberkholz@> that's me, Cardoe, Halcy0n
+20:28 <musikc|lap > haha, sorry!
+20:29 < dberkholz@> lu_zero hasn't agreed & i'm not entirely clear on dertobi123
+20:29 <musikc|lap > <Cardoe> my opinion is that it should be up to devrel
+20:29 < dberkholz@> Betelgeuse is probably eating popcorn
+20:29 <Betelgeuse@> :D
+20:29 <Betelgeuse@> I really should by some.
+20:29 < Cardoe+> dberkholz: are you waiting on me?
+20:29 < lu_zero@> dberkholz I consider it part of the retirement process
+20:29 < dberkholz@> Cardoe: nope
+20:30 < dberkholz@> lu_zero: ok, so you're fine with devrel deciding how to handle it?
+20:30 <musikc|lap > Cardoe, i was just posting your comment as it was the shortest one to sum it all up :)
+20:30 < lu_zero@> dberkholz it's devrel task to retire people
+20:30 < dberkholz@> i'll take that as a yes
+20:30 <Betelgeuse@> I think it probably should be in the retirement process if the question is being retired due the continuing bad behaviour.
+20:31 <Betelgeuse@> s/probably//
+20:31 < dberkholz@> ok. now it indeed does seem that we've reached agreement
+20:31 < dberkholz@> right on time, too
+20:31 <musikc|lap > ;)
+20:31 < lu_zero@> good
+20:32 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0: Conflict resolution
+20:32 < fmccor > How far back does this go? Would you ban someone fro #gentoo-dev, say, today for something that happened 2 years ago?
+20:33 < fmccor > That strikes me as silly.
+20:33 < dberkholz@> devrel's making the policy
+20:33 < dberkholz@> discuss it amongst yourselves =)
+20:33 < dberkholz@> we're talking about EAPI 0
+20:33 <Betelgeuse@> fmccor: The retirement process is done for those people as far as I am concerned.
+20:34 < dberkholz@> ok, the main thing we came up with last meeting on PMS is figuring out how to handle conflict resolution
+20:34 <Betelgeuse@> I vote that we start voting on issues one by one.
+20:34 < lu_zero@> ?
+20:34 < dberkholz@> i tossed some ideas into the agenda
+20:35 <Betelgeuse@> Bugzilla should work as a platform.
+20:35 < dberkholz@> Betelgeuse: "we" being council?
+20:35 < ciaranm > i didn't see the promised "we'll mail the list with opinions" emails for this. where should i have been looking?
+20:35 <Betelgeuse@> dberkholz: yes
+20:35 < Cardoe+> I had suggested (but not mentioned on the ML yet) that a 3rd party is appointed by the council to be the "merge master" to merge in changes to the PMS. When a conflict arises, the merge master will attempt to work with the parties involved and the issue resolved. If no resolution can be easily reached, the issue is referred to the council who will direct the merge master which way to go.
+20:35 < dberkholz@> ciaranm: yeah, that was full of fail.
+20:35 < ciaranm > heh, fairy nuff
+20:36 < dberkholz@> i threw the idea i just thought of into the agenda
+20:36 < dberkholz@> which is asking PMS & portage devs to come up with a process for conflict resolution that they both agree to follow
+20:36 < Halcy0n@> I think I hit all of the topics except this on the mailing list because I wanted to put some thought into it. I have some ideas that I need to write up and I want to see discussed though.
+20:37 < dberkholz@> seems like everyone might be happier going along with a process you came up with yourselves
+20:37 <Betelgeuse@> dberkholz: but is that likely to happen?
+20:37 < ciaranm > part of the problem with conflict resolution is what to do when portage makes non-EAPIed changes that break lots of existing packages
+20:37 < dberkholz@> and i tried to put some ideas out there for what that process might be
+20:37 < dberkholz@> but i think agreement has to begin with the involved people
+20:37 < spb > ciaranm: you file a bug, and it gets marked WONTFIX
+20:37 <musikc|lap > ciaranm, wouldnt that not be part of the problem but the main reason being when any PM does that?
+20:37 < lu_zero@> ciaranm do you have a list?
+20:38 < dberkholz@> we were talking about the list last meeting and wasted a lot of time on details that aren't relevant to us
+20:38 < ciaranm > musikc|laptop: you could argue that, yes
+20:38 < ciaranm > lu_zero: er, phase order changes and --jobs are the canonical examples
+20:38 < spb > lu_zero: --jobs and phase ordering changes will do to start with
+20:38 <musikc|lap > ciaranm, just seems to be the basis for a need for a conf res
+20:38 < lu_zero@> a list of ebuilds
+20:38 < lu_zero@> anyway unrelated to the current topic
+20:39 < dberkholz@> ciaranm & spb: while you're here, do you have any good ideas for the resolution process?
+20:39 <Betelgeuse@> lu_zero: It's not totally unrelated.
+20:39 < ciaranm > dberkholz: i've yet to get anything out of zac that isn't "i'll do whatever i want with portage, even if it breaks existing ebuilds and even if it goes completely against the gentoo documentation"
+20:39 <dleverton_ > lu_zero: no-one can know which ebuilds are broken without carefully examining the entire tree.
+20:40 < spb > dberkholz: the most obvious is if some person can be found with enough knowledge of the problems in question to act as a sensible arbitrator
+20:40 < ciaranm > dberkholz: really, "throw anything we can't agree upon to the council" would be fine, if i get assurances that the council will override zac if he does something stupid, and that the council will step in if zac decides to ignore PMS anyway on something the council's decided upon
+20:40 <Betelgeuse@> ciaranm: I am willing to do that.
+20:40 < spb > unfortunately most such people that i can think of are already working on pms, so the next option is just to refer disputes to the council
+20:41 < dberkholz@> ok, basically the first two mentioned in the agenda
+20:41 < ciaranm > the problem with resolving conflicts is that anything we do currently that isn't "whatever zac says, even if it means breaking lots of existing packages" gets turned into "pms has to document what portage does, for some random version of portage that most people aren't using"
+20:41 < ciaranm > which i don't see as being a sensible way of getting things done
+20:41 < spb > even when that contradicts the version of portage that people are using
+20:42 <musikc|lap > dberkholz, it seems that the suggestion of neutral third party for PMS sounds sane since ciaranm continually points out his concerns with working with zac
+20:42 < dberkholz@> yes, we clearly need zac, genone, and anyone else to buy into whatever the process is
+20:42 < ciaranm > do we even need a neutral third party? the volume of things where there are conflicts is probably low enough not to overload the council
+20:42 <Betelgeuse@> musikc|laptop: I don't really see how a gentoo dev would be totally neutral.
+20:42 < ciaranm > it'll give you a technical topic to discuss every other month or so if nothing else :P
+20:42 < ferdy > musikc|laptop: how does a 'neutral' (who decides upon neutrality?) person help there?
+20:43 < ciaranm > also, if we had a neutral person to spare, their time could be better spent contributing content
+20:43 < dberkholz@> i agree, actually. i think the council is a pretty reasonable group to do this
+20:43 < lu_zero@> looks like at least some like the idea to have the council handle conflicts
+20:44 <musikc|lap > what about having non PM's work on the PMS doc so it reflects the opinions of the community?
+20:44 < ciaranm > make that "have the council handle conflicts if the pms editors can't sort it out"
+20:44 < lu_zero@> zmedico and ferringb is that ok for you as well?
+20:44 < ciaranm > musikc|laptop: there shouldn't be opinion in pms
+20:44 < zmedico > lu_zero: seems fair enough to me
+20:44 <musikc|lap > ciaranm, a standard is a collection of opinions put to 'law' as it were
+20:44 < ciaranm > musikc|laptop: and we've never rejected a patch (except "resend with this fixed", which has always happened) from non PM people
+20:44 < spb > musikc|laptop: frankly, the opinion of the community is irrelevant to a purely technical document
+20:44 <musikc|lap > spb, depends on who the community is imo
+20:45 < spb > it documents existing behaviour
+20:45 < spb > there's no room for opinion in that
+20:45 < ciaranm > the problem with asking the community is that people say what they think *should* happen, which isn't what pms is dealing with
+20:45 <musikc|lap > spb, if it documents existing behavior then existing behavior of which PM?
+20:45 < ciaranm > pms has to deal with what *does* happen wherever possible
+20:45 < ferringb > lu_zero: what, punting up to council?
+20:45 < dberkholz@> ferringb: yeah
+20:46 < ciaranm > what *should* happen is "future EAPI" territory
+20:46 < spb > musikc|laptop: the best compromise that can be made between all vaguely recent portage versions and the tree
+20:46 < ferringb > dberkholz: not sure you'll like the volume, going by past disagreements tbh. things may've changed (these days I stay out of orbit) however.
+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 < spb > where vaguely recent means "is likely to be in use by someone somewhere, or was stable some time in the last six months to a year"
+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 < lu_zero@> ferringb do you have alternative proposals?
+20:47 < ciaranm > dberkholz: so long as the council's prepared to follow through with its resolutions
+20:47 < ciaranm > ferringb: please provide a list of patches of yours that we've rejected
+20:48 <musikc|lap > ciaranm, or could you provide a list of packages you accepted? might be just as easy :)
+20:48 <musikc|lap > s/packages/patches
+20:49 < spb > that's only meaningful when compared to the list of patches that were submitted
+20:49 <Betelgeuse@> musikc|laptop: I can say for myself that I havent' had problems getting my patches in.
+20:49 < ferringb > ciaranm: past discussions
+20:49 < ciaranm > musikc|laptop: we've accepted (sometimes after asking for revisions) every patch that's been sent
+20:49 < ferringb > ciaranm: not much point in pushing a patch up if it's already estabilished it has zero chance of getting in w/ folk in control.
+20:49 <musikc|lap > ciaranm, just saying either party could validate
+20:49 < dberkholz@> ok
+20:49 < ciaranm > musikc|laptop: well, i've rejected exactly zero of ferringb's contributions so far
+20:49 < ferringb > either way, council as arbitrator flies.
+20:50 * ferringb sighs; now we're getting into word play re: definition of 'contributions'
+20:50 < lu_zero@> looks like this topic could be voted on
+20:50 < jokey@> better do not do it here and now
+20:50 < jokey@> lu_zero++
+20:50 < dberkholz@> ok, we've gotten people from all the groups to buy in
+20:51 < dberkholz@> it's definitely worth trying something new, and if this doesn't work, we can try to make the whole neutral person thing work
+20:51 < dberkholz@> i'm for it
+20:51 <dertobi123@> let's give it a try and see if that process works
+20:51 <dertobi123@> so yes
+20:52 < lu_zero@> anybody against?
+20:52 <musikc|lap > so council will vote on any conflicts that arise from the PMS not being followed?
+20:52 < Cardoe+> might as well just do a formal yes so no one says someone was asleep at the wheel.
+20:52 < ciaranm > does this also mean we're taking pms as being definitive except where there're disagreements? which was the original question, really
+20:53 * ferringb notes management of pms vs it being definitive are two seperate questions
+20:53 <jmbsvicett > If that's the case, then perhaps it would be a good idea to have people mail their disagreements so they can be worked out
+20:53 < dberkholz@> you're right, that was the original question
+20:54 <musikc|lap > ferringb, yes that makes sense to me as well
+20:54 < Cardoe+> ciaranm: I'd say yes
+20:54 < lu_zero@> but isn't what's on topic...
+20:54 < spb > ferringb: and when the original question was put to the council last time around, the answer that i can recall was that what still needed sorting out was a conflict resolution method
+20:54 <musikc|lap > we're well past the 15 minutes, will council be voting on the conf res process or should that wait 2 weeks?
+20:54 < lu_zero@> could we just close one and move to the other ^^?
+20:54 <Betelgeuse@> Cardoe: yes
+20:54 < dberkholz@> ok. conflict resolution is handled
+20:55 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0: Other issues?
+20:55 <musikc|lap > dberkholz, not to be confused with management of PMS as ferringb pointed out?
+20:55 < dberkholz@> we have about 5 minutes, so just bring up anything that's holding it back and we won't try to discuss it now
+20:56 <musikc|lap > i dont think anyone agrees, or if so i apologize for forgetting, that it is good to have a package manager standard. just how that is managed seems to be in disagreement.
+20:56 < ferringb > musikc|laptop: think you screwed up your phrasing there
+20:56 < zmedico > s/agrees/disagrees/
+20:56 <musikc|lap > hahah
+20:56 <musikc|lap > yes and yes
+20:57 < dberkholz@> so ferringb & zmedico think having a standard is worthwhile. that's accurate, yes?
+20:57 < ferringb > dberkholz: I'd add a few adjectives in there, but yes
+20:57 < dberkholz@> and by standard i mean a written spec
+20:57 < zmedico > yes, it's useful
+20:58 < dberkholz@> since we've had some vague discussions in the past about that, so i'm glad all the relevant people are on the same page
+20:58 < lu_zero@> still I have concern of the form of the spec
+20:58 < ciaranm > lu_zero: specifics please?
+20:58 < lu_zero@> ciaranm in short?
+20:58 < ciaranm > lu_zero: something concrete so i can say either "yes, we can improve that" or explain why i think it's correct the way it is
+20:58 < lu_zero@> an article/scientific paper isn't a spec, an rfc comes closer
+20:59 < Halcy0n@> We are about to hit 5pm, and I have a meeting right now (at work), so I must run.
+20:59 < ciaranm > the reason we're not writing it to rfc standards is that we don't have the manpower to produce a loophole-free spec
+20:59 < ciaranm > i'd take patches to rephrase individual sections to be more watertight if people think they can do it
+20:59 <musikc|lap > dberkholz, meeting officially wraps up on the hour, correct?
+21:00 < dberkholz@> zmedico, ferringb: i'd really love to see emails from you and any other PM developers describing what you think about PMS being a draft standard of EAPI 0.
+21:00 < ciaranm > but producing a spec that can't be deliberately misinterpreted would take a hell of a lot longer than producing one that assumes a sensible and cooperative reader
+21:00 < spb > and there's little point making it utterly free from loopholes when there's a well defined process for handling disagreements
+21:00 < lu_zero@> ciaranm I recall I asked abnf sections
+21:00 < dberkholz@> we need to wrap up now
+21:00 < ciaranm > lu_zero: abnf ends up being less readable than the written form
+21:00 <NeddySeago > ciaranm there is no such thing as a loophole-free spec, someone sometime will always find a meaning that was not intended
+21:00 < lu_zero@> but is machine parsable
+21:01 < lu_zero@> and it's quite easy get a checker out of it
+21:01 < dberkholz@> zmedico, ferringb: there's already the existing thread on gentoo-dev for the last council meeting, so you can just reply there
+21:01 < ciaranm > NeddySeagoon: 'loophole-free' is what ISO aims for
+21:01 < spb > NeddySeagoon: which is precisely why we're not trying to write one
+21:01 <NeddySeago > ciaranm Yep ... its a good aim
+21:01 < ciaranm > lu_zero: the problem is, a grammar for specs ends up being very very horrid
+21:01 * musikc|l also has a RL meeting now
+21:01 < lu_zero@> ciaranm rfc2234 isn't _THAT_ ugly
+21:01 <musikc|lap > verifying this one is done?
+21:01 < Cardoe+> now we're arguing semantics
+21:02 < dberkholz@> it's past 2100, so the meeting is over. everyone with a stake in the spec really needs to email -dev about any issues with it becoming a draft standard
+21:02 < ferringb > dberkholz: presume 2 week window or so?
+21:02 < ciaranm > lu_zero: try, say, iso c++ draft n2723 section 14.7 if you want an example of just how bad formal specs get
+21:02 < dberkholz@> we'll resume at the next meeting and approve it unless there are objections between now and then
+21:02 <jmbsvicett > If there's an agreement about EAPI-2 in the mls prior to the next council meeting, will you be willing to vote on it?
+21:02 < dberkholz@> that'll be ... sept 11
diff --git a/meeting-logs/20080911-summary.txt b/meeting-logs/20080911-summary.txt
new file mode 100644
index 0000000..849b0c7
--- /dev/null
+++ b/meeting-logs/20080911-summary.txt
@@ -0,0 +1,54 @@
+Roll call
+=========
+betelgeuse here [calchan]
+dberkholz here
+dertobi123 here
+halcy0n here
+jokey slacker
+lu_zero slacker
+
+
+First
+=====
+
+Filling the empty slot
+----------------------
+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.
+
+
+Old topics
+==========
+
+PMS as a draft standard of EAPI 0
+---------------------------------
+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.
+
+Goal: Vote whether to approve PMS as a draft standard of EAPI 0.
+
+Requirements:
+
+ - There needs to be a PMS lead who is a Gentoo dev [calchan].
+ Both cardoe & antarus volunteered if this was needed.
+ - Document the conflict resolution process that we agreed upon last
+ week [calchan].
+ - Document the patch acceptance process [halcy0n].
+ - Create a public mailing list so discussions & patches aren't lost on
+ the pms-bugs alias [cardoe].
+
+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.
+
+
+New topics
+==========
+
+None.
diff --git a/meeting-logs/20080911.txt b/meeting-logs/20080911.txt
new file mode 100644
index 0000000..8885430
--- /dev/null
+++ b/meeting-logs/20080911.txt
@@ -0,0 +1,317 @@
+20:00 < Halcy0n@> Alright, so roll-call...who is here?
+20:01 -!- mode/#gentoo-council [+v Cardoe] by Halcy0n
+20:01 <dertobi123@> <-
+20:02 * Calchan is proxying for Betelgeuse
+20:02 -!- mode/#gentoo-council [+v Calchan] by Halcy0n
+20:02 < Halcy0n@> Yup, saw the email earlier as well. Thanks
+20:02 <dberkholz|@> here
+20:03 < Halcy0n@> jokey or cardoe?
+20:04 < Cardoe+> sorry
+20:04 < Cardoe+> Halcy0n: technically I'm not on the roll call yet since Diego resigned so I'm not officially taking his position
+20:05 < Cardoe+> Halcy0n: and you guys have to vote for the next person on the ballot to take his place
+20:05 < Halcy0n@> Cardoe: true, but its good you are here anyhow since that's the first discussion point.
+20:05 <dertobi123@> i tried to call jokey on his cellÃphone, no success :/
+20:05 < Halcy0n@> Well, is everyone that is here ready to start then? jokey and lu_zero seem to be MIA.
+20:07 -!- Halcy0n changed the topic of #gentoo-council to: Next meeting: 2000 UTC Sept. 11 - Agenda: http://archives.gentoo.org/gentoo-dev/msg_619e8ac19efadb77a5c24add7a7b529b.xml - #1 Filling the empty slot
+20:07 < Cardoe+> oo Halcy0n has the shiny gavel today
+20:07 < Halcy0n@> Cardoe: well, since it looks like dberkholz|bb is on his blackberry, I figured it would be easier if I took the lead :P
+20:09 < Halcy0n@> So, last time the council voted in the next person in line when a council member retired. Is everyone that is present ready to vote on whether or not to follow what was done last time? This would mean Cardoe would become our 7th council member in Diego's place.
+20:09 <dberkholz|@> we only need 4 to vote
+20:10 < Cardoe+> as a reference point, http://article.gmane.org/gmane.linux.gentoo.devel.announce/243 are the results from the election officials
+20:10 <dberkholz|@> I'm ready
+20:10 <dertobi123@> <- ready to vote
+20:10 < Calchan+> ready too
+20:11 <dberkholz|@> mark?
+20:11 < Halcy0n@> Yup. It has a yes from me.
+20:11 <dberkholz|@> Same here -- yes
+20:11 < Calchan+> yes from me too
+20:11 <dertobi123@> yes here, too
+20:12 < Halcy0n@> Congrats Cardoe :)
+20:12 <dberkholz|@> cardoe: welcome to the caba... er, council!
+20:12 < Cardoe+> heh thank you
+20:12 < Calchan+> Cardoe, all other choices were worse ;o)
+20:13 < Cardoe+> Calchan: hah. Sounds like a Futurama quote
+20:13 <dberkholz|@> remember to get the mail alias updated
+20:13 < Calchan+> is this effective now ?
+20:13 <dberkholz|@> yep
+20:13 < Calchan+> ok
+20:13 -!- Halcy0n changed the topic of #gentoo-council to: Next meeting: 2000 UTC Sept. 11 - Agenda: http://archives.gentoo.org/gentoo-dev/msg_619e8ac19efadb77a5c24add7a7b529b.xml - #2 PMS as a draft standard of EAPI 0
+20:14 <dberkholz|@> since we got conflict resolution figured out, I haven't heard any other blockers
+20:15 < Halcy0n@> I haven't seen any issues raise, so I'm assuming the PM developers are fine with it.
+20:15 < Calchan+> dberkholz|bb, do we have gentoo dev in charge ?
+20:16 <dberkholz|@> does it matter, if we have a way to resolve conflicts with portage, and the council has to approve it?
+20:16 < Cardoe+> Calchan: not exactly. It's technically a sub-project of QA, which is Halcy0n's dept.
+20:16 < Cardoe+> Calchan: however, it's something that's being driven by the developers of the Package Managers with a conflict resolution policy in place
+20:17 < Cardoe+> which is they try to work it out among themselves, there are 3 after all so that's a pretty easy way to get a majority vote
+20:17 < Calchan+> I haven't seen the mail on the conflict resolution thing
+20:17 < Cardoe+> and if it doesn't work, it gets kicked up to the council
+20:17 < ciaranm > a majority isn't enough. we're not microsoft...
+20:18 < Calchan+> who are the 3 ?
+20:18 < Cardoe+> Calchan: Portage, Paludis, and pkgcore
+20:18 < ciaranm > zac for portage, ferringb for pkgcore, about ten of us for paludis
+20:18 < Calchan+> oh, I thought you were talking about persons
+20:19 < Calchan+> and who's doing the conflict resolution ? (anybody got a pointer to the mail ?)
+20:20 < ciaranm > Calchan: the pms editors, if possible, and the council if we can't get everyone to agree
+20:20 < Calchan+> ciaranm, thanks, and who are the pms editors ?
+20:20 < Halcy0n@> This still seems like somewhat of a undocumented process to me. I'd really like there to be some structure to something as important as this.
+20:20 < musikc > so PMS is maintained by zmedico, ferringb, and ciaranm? i thought it was just ciaranm and spb?
+20:20 < Calchan+> Halcy0n, this is where I was getting at
+20:20 < ciaranm > Calchan: me and spb are editors at the moment
+20:20 < Calchan+> musikc, this was my impression too
+20:20 < Cardoe+> Halcy0n: I was going to suggest a patch to the pms.xml
+20:21 < musikc > ciaranm, shouldnt all of you be editors?
+20:21 < ciaranm > musikc: anyone who sends lots of good patches can be an editor if they want
+20:21 < musikc > since it's a collaboration and not led by any one PM?
+20:21 < antarus > musikc: no one else has asked...
+20:21 < spb > pms is just like any other open source project
+20:21 < Calchan+> ciaranm, please define "lots of good patches" and who will decide
+20:21 < spb > it's developed by those who develop it
+20:21 < musikc > so zmedico and ferringb have access to edit it as well then?
+20:22 <jmbsvicett > antarus: Are you sure they were willing or they had reasons to expect becoming editors?
+20:22 < musikc > they should have the same access to edit the doc since its a group effort
+20:22 < ciaranm > Calchan: i'll define that when someone asks
+20:22 < ciaranm > musikc: they can send patches, same as everyone else
+20:22 < musikc > why patches?
+20:22 < musikc > why cant they edit it?
+20:22 < musikc > who gets to decide what goes in and what doesnt?
+20:22 < ColdWind > musikc: if they haven't sent patches, why would they need access?
+20:22 < ciaranm > because nothing gets committed to pms without peer review
+20:22 < musikc > who gets to say what a good patch is?
+20:22 < zmedico > honestly I'm perfectly happy leaving others to edit PMS. I've got other things to work on.
+20:23 < Calchan+> ciaranm, you'll define ? sorry, unacceptable
+20:23 < ciaranm > musikc: anyone who wants to can review patches and raise objections
+20:23 < musikc > ciaranm, ok that makes sense. who are the peers?
+20:23 < ciaranm > musikc: anyone who wants to do reviewing can do so
+20:23 < spb > anyone who's watching the pms-bugs alias
+20:23 < antarus > I should correct that
+20:23 < antarus > 'anyone knowledgeable who wants to do reviewing' ;p
+20:23 < spb > since any changes go there for people to complain before they're committed
+20:23 < dberkholz@> ok, i'm on my laptop now
+20:23 < musikc > ciaranm, so only you and spb have commit access and final say unless someone wants to escalate to council?
+20:23 < ciaranm > Calchan: why? it's not an issue yet, and if it ever becomes one we can raise it to the council if necessary
+20:24 < ciaranm > musikc: for now, yes, since no-one else has asked
+20:24 < Calchan+> Halcy0n, we obviously need a gentoo dev in charge here, and if that's not you we need somebody to volunteer
+20:24 <Philantrop > musikc: The same discussion was held during the last meeting and that's how the escalation process got created.
+20:24 < antarus > Calchan: why is it obvious?
+20:24 <dleverton_ > "Obviously"?
+20:24 < spb > musikc: ultimately, the council has final say since any disagreements can get escalated there
+20:24 < ciaranm > Calchan: what's wrong with the current process? specific examples of where it's gone wrong please.
+20:24 < musikc > Philantrop, i thought the escalation process was for any conflicts. i recall ciaranm stating what if PM's didnt follow PMS, hence the need for resolution process
+20:25 < dberkholz@> it seems clear to me that as a QA subproject, Halcy0n would have the final say on who could commit to it, although if there happens to be a specific pms lead, or consensus by the existing pms team, that would also be fine
+20:25 < ciaranm > musikc: you mean the resolution process being "if we can't work it out then we send it to the council", which is what's being discussed?
+20:25 < Calchan+> ciaranm, if it's a gentoo project it needs a gentoo dev as lead, if it's an external project I don't know why we're discussing it
+20:25 < ciaranm > Calchan: uh, since when?
+20:26 < ColdWind > Calchan: what does that gentoo dev need to do?
+20:26 < musikc > dberkholz, ya, it'd make sense if there was a lead or representation from all PM's
+20:26 < spb > there's representation from anyone who sees bugs and writes patches
+20:26 < ciaranm > *if* anyone ever has a problem that can't be resolved, they can just ask the council to discuss it. what's the problem?
+20:26 < Halcy0n@> dberkholz: to me, this seems to still be a hot topic that clearly isn't getting the discussion it deserves on the mailing lists. I'd recommend the council members bringing up their concerns so its all documented somewhere.
+20:27 < antarus > this is all irrelevant to the actual question
+20:27 < antarus > which was is PMS the draft spec for EAPI 0
+20:27 < antarus > yes/no?
+20:27 <Philantrop > antarus++
+20:27 < Cardoe+> I'm actually working on a revised pms page for the QA sub-project
+20:27 < antarus > I don't think 'who can commit to PMS' has anything to do with that
+20:27 < musikc > Halcy0n, makes sense to me
+20:27 < Calchan+> Halcy0n, makes sense to me too
+20:28 < lack > antarus: 'PMS' as in a snapshot of what the repository is now, or 'PMS' as in the entire future of the repository's contents?
+20:28 < antarus > you can discuss all teh beauracratic bullshit later ;p
+20:28 < ciaranm > wasn't this "sent to the mailing lists" last month?
+20:28 < ciaranm > why weren't objections raised then?
+20:28 <jmbsvicett > antarus: Last time there were 2 or 3 issues on the draft that were raised as not being accepted by all parties
+20:28 < dberkholz@> that's a good question.
+20:28 < musikc > ciaranm, that was 2 weeks ago, perhaps peoples obligations delayed responses?
+20:28 <jmbsvicett > antarus: There was also a request to present all such issues to the mls - I didn't notice any mails about them
+20:28 < ciaranm > musikc: for two weeks?
+20:28 < musikc > seems to spark questions again, whats the problem with suggesting it goes to the mailing list
+20:29 <Philantrop > jmbsvicetto: Which seems to imply that these issues were resolved.
+20:29 < musikc > ciaranm, sure. i myself was on vacation and in the middle of a lot of project work. just one person's example.
+20:29 < ciaranm > musikc: i was hoping for a decision three months ago...
+20:29 < Cardoe+> musikc: You seem to have some objections. Please send them to the list.
+20:29 < antarus > Philantrop: no it implies no one talked about them ;)
+20:29 <Philantrop > antarus: Actually, I know they were talked about. :-)
+20:29 < antarus > if it goes back to the lists you should set a deadline
+20:29 < musikc > Cardoe, not so much objections as thoughts and interest in wht other people think
+20:29 < ColdWind > the same problem is going on since way before the last meeting iirc, and it never gets discussed on the ML
+20:29 < musikc > antarus, that makes complete sense also
+20:29 < antarus > such that issusea are actively being resolved before the deadline
+20:29 < antarus > otherwise we will discuss this forever
+20:30 < ColdWind > it seems you've entered a deadlock
+20:30 < dberkholz@> at least having a council meeting every 2 weeks forces people to bring it up that often.
+20:30 < ciaranm > every two weeks people ask the same questions that were asked four weeks ago
+20:30 < antarus > so we are not ready to vote because there were issues from last meeting that were not resolved?
+20:30 < antarus > you have 2 weeks to fix them
+20:30 < antarus > lets move on ;p
+20:30 < dberkholz@> i'm trying to put together a list of things people say are blockers
+20:30 < dberkholz@> could whoever had one please say it again, directed at me?
+20:31 < musikc > blockers?
+20:31 < dberkholz@> we don't want to delay this without specific things that need to be resolved before approving it
+20:31 < Calchan+> dberkholz, lead, doc on structure and processes
+20:31 <Philantrop > dberkholz: Please consider the topic and the iussues that were raised here today.
+20:31 < dberkholz@> otherwise it goes into the nebulous nowhere
+20:31 < musikc > ahhhh, agree with Calchan
+20:31 < Calchan+> dberkholz, was the conflict resolution discussed on council@ ?
+20:31 < Halcy0n@> dberkholz: what calchan said. I'd like to see a process since it seems people aren't clear on it.
+20:31 < antarus > I will volunteer as lead if you need for one some reason
+20:32 * antarus shrugs
+20:32 < dberkholz@> Halcy0n: a process for what?
+20:32 * musikc votes Halcy0n for lead :)
+20:32 < musikc > HEHE
+20:32 < ciaranm > antarus: i've already got a volunteer gentoo developer to be an arbitrary and pointless figurehead if anyone needs one
+20:32 < antarus > ciaranm: ok :)
+20:32 < Calchan+> dberkholz, I was talking about conflict resolution, I haven't seen anything
+20:32 < dberkholz@> Calchan: it was agreed upon at the last meeting. first PM devs & PMS editors try to resolve, and they request council to resolve by vote if they cannot
+20:32 < ciaranm > Calchan: did you see what was discussed at the last meeting?
+20:32 <jmbsvicett > dberkholz / Halcy0n: People should also raise any objection to the current content of the PMS draft, before it gets approved
+20:33 < ciaranm > jmbsvicetto: did you see what the question was?
+20:33 < Cardoe+> ciaranm: me? or someone else. Cause I volunteered a few weeks back if that would ease the approval of this.
+20:33 < musikc > jmbsvicetto, good point. has that been raised by anyone yet?
+20:33 < ciaranm > Cardoe: oh, you're number three then :P
+20:33 < ciaranm > musikc: why is it a good point? include references to the question in your answer
+20:33 <jmbsvicett > ciaranm: I did. That's why I'm saying anyone with any objection has a last chance to present it before the doc gets approved - "speak now, ..."
+20:33 < Calchan+> dberkholz, then who are the pms editors ? where is this documented ?
+20:33 < ciaranm > jmbsvicetto: er, why is there a last chance?
+20:33 < Cardoe+> Does anyone have any objections to the current content of the PMS?
+20:33 < musikc > ciaranm, what was my question? i think you confised me with someone else
+20:34 < ciaranm > jmbsvicetto: clearly you *didn't* read the question
+20:34 < ciaranm > musikc: you agreeing with jmbsvicetto. i want to know why you're doing that.
+20:34 < ciaranm > especially given how spb specifically covered it being ok to find issues with the EAPI 0 definition even after the level of approval being requested
+20:35 < musikc > b/c i agree with him saying that people should raise any objections to the current content before it gets approved. sounds reasonable to me. :)
+20:35 < Calchan+> Cardoe, I have no problem with the content
+20:35 < ciaranm > except that we're not asking for and never will ask for "this will never change" approval
+20:35 <jmbsvicett > ciaranm: Let me be clear. dberkholz is trying to collect issues about PMS and its approval. I'm suggesting that in the next 2 weeks anyone having the slightest objection to the current content of the draft should sent it to the ml and have it discussed before the doc is approved - otherwise, they'll have to live with the doc. This is all I'm saying
+20:35 < musikc > ciaranm, i understand the concept of 'fluid' documents, thanks though
+20:35 < ciaranm > musikc: then why are you agreeing with jmbsvicetto over "last chance"?
+20:35 <Philantrop > jmbsvicetto: That has been the case for *months* now and nothing was brought up.
+20:36 < ciaranm > jmbsvicetto: how does that differ from the last three times that's been said?
+20:36 < Halcy0n@> Lets get back on topic here. The underlying question is should we approve PMS as a draft for EAPI 0 only. We seem to have some other major concerns, and we should leave it open for us to amend this decision later.
+20:36 < musikc > ciaranm, b/c if someone has an objection currently, wouldnt it make sense that they bring it up? why wait. seems silly if they already know they have an objection.
+20:36 < dberkholz@> ok, i have 2 issues as blockers right now
+20:36 < musikc > Halcy0n ++
+20:36 <Philantrop > Halcy0n: The concerns are about process, not the contents, though.
+20:36 < dberkholz@> one is a PMS lead who is a gentoo dev, and the other is documenting conflict resolution
+20:36 <jmbsvicett > Philantrop: true, but it seems no one has ever felt it as a "deadline"
+20:37 < antarus > Philantrop: processes are important
+20:37 < ciaranm > every time we do this a different group of people jumps up and asks the same questions that were asked at the previous meeting, and then it's always postponed to the next meeting for the same questions to be asked over again
+20:37 < antarus > (certainly I'm with you that this should have been approved months ago)
+20:37 <Philantrop > antarus: Yes, if they don't work.
+20:37 < musikc > dberkholz, i dont see the process for approval of patches, etc documented. that'd probably be worthwhile as well
+20:37 < antarus > that doesn't mean we shouldn't attempt to document how things work now ;p
+20:37 < Halcy0n@> Can we stay on topic please? I have other things I need to run to after this.
+20:38 < ColdWind > So, on one hand, people is not discussing problems with the contents even when that's what's council requested for months. On the other hand, people can still bring up those concerns after PMS approval as a draft standard... that's why it's a draft. Is there any reason to block the approval of the draft forever?
+20:38 < musikc > ColdWind, forever? of course not. postponed while ppl still work to understand the process? sure.
+20:38 < Halcy0n@> Calchan, Cardoe, dberkholz|bb : Are you guys comfortable with the statement I made above? Lets vote on whether or not to approve PMS as a draft for EAPI 0 only, and leave it open for us to amend the decision later should we find the need to.
+20:38 < antarus > ColdWind: thats what the two week deadline is for ;)
+20:38 < Cardoe+> Halcy0n: yes
+20:39 < dberkholz@> do any council members think that documenting a process for patch acceptance is a requirement?
+20:39 < Halcy0n@> dertobi123: ^ that was directed to you as well
+20:39 < ColdWind > musikc: there will be *always* someone who still doesn't understands the process, so yes, with this dynamic... this is effectively blocked forever.
+20:40 < musikc > ColdWind, agreed so documentation helps :)
+20:40 < Halcy0n@> dberkholz: I don't see it as a blocker for approving it as an initial draft right now, but I want it documented.
+20:40 < Cardoe+> alright. everyone let's take a breather for a second. Let's us wrap up the actual question at hand. Further concerns can be approached on list.
+20:40 <dertobi123@> Halcy0n: yep
+20:40 <Calchan|Ho > sorry, apparently my irc proxy went down
+20:41 < musikc > so post poned until documented Halcy0n?
+20:41 < Calchan+> ColdWind,
+20:41 < Cardoe+> ciaranm: what's the official ml to bring up discussions about patches? or should it remain on the bug?
+20:41 < ciaranm > Cardoe: we're using the pms-bugs alias for now
+20:41 < Halcy0n@> musikc: no, I don't mind doing the initial approval, and getting the documentation laid down afterwards.
+20:41 * musikc nods
+20:42 < Cardoe+> ciaranm: any requirements to join the alias? or just get someone with commit access to that file to add you?
+20:42 < musikc > Halcy0n, that makes sense and goes with ciaranm's expressed view of PMS always up for change
+20:42 < ciaranm > Cardoe: the only requirement is that you not be so amazingly annoying that we feel obliged to move somewhere else
+20:42 < dberkholz@> could you tone it down a bit, ciaranm ..
+20:42 < musikc > ciaranm, any gentoo dev should be welcome since PMS is a standard for Gentoo :)
+20:43 < Halcy0n@> Council people, are we ready to vote?
+20:43 < Cardoe+> Halcy0n: yes
+20:43 < Calchan+> I'm ready to vote
+20:43 < ciaranm > dberkholz: mm? what did i say?
+20:43 <dertobi123@> yes
+20:43 < ciaranm > musikc: any qualified gentoo developer
+20:43 < musikc > ciaranm, who determines who is qualified?
+20:43 < ciaranm > any qualified anyone. being a gentoo developer is neither here not there
+20:43 < musikc > Gentoo has determined any dev is qualified as this is a standard for Gentoo so they should all be welcome
+20:43 < ciaranm > musikc: it's yet to be an issue, so we haven't had to determine it
+20:44 < Halcy0n@> dberkholz: are you?
+20:44 < musikc > ciaranm, so all Gentoo devs should be welcome
+20:44 < dberkholz@> Halcy0n: i'm thinking
+20:44 < ciaranm > musikc: dunno. does gentoo still have developers who don't know what 'grep' is?
+20:44 -!- mode/#gentoo-council [+m] by Halcy0n
+20:44 < Halcy0n@> Just to reduce the noise so we can make a decision on the original topic.
+20:45 <dertobi123@> thanks Halcy0n
+20:45 < dberkholz@> here's what i'm thinking. we have these 2 blocking issues. will either of them have an impact on pms as a draft standard?
+20:45 < Cardoe+> dberkholz: what do you see as the two?
+20:45 < dberkholz@> the two i said earlier
+20:46 < dberkholz@> 20:36 < dberkholz@> one is a PMS lead who is a gentoo dev, and the other is documenting conflict resolution
+20:47 <dertobi123@> one of these issues is about having a puppet or not having a puppet as a lead, this is a non-issue from my pov
+20:47 < dberkholz@> what exact benefits would having a pms lead as a gentoo dev gain us?
+20:47 < Calchan+> dberkholz, a half baked pms project is the best way to have it crash into a wall, so we want this ?
+20:47 < Calchan+> s/so/do/
+20:47 < Halcy0n@> dberkholz: if we want the project to remain useful, I think we should document it before we start pushing it on people as a standard, in draft form or any other.
+20:48 < Cardoe+> While people might feel emotional about a PMS lead that is a Gentoo dev, it's not necessarily a requirement. It's a Gentoo project controlled by the Gentoo QA project as a whole. Who runs the PMS sub-project is no consequence to how good or bad it is.
+20:48 < dberkholz@> document what?
+20:48 < Halcy0n@> dberkholz: sorry, the conflict resolution and patch approval process.
+20:49 < Cardoe+> Halcy0n: do we want to create a pms ML so that the pms-bugs alias isn't being used/abused?
+20:49 < Cardoe+> bugzilla can mail changes to the ML for affected bugs
+20:49 <dertobi123@> Cardoe: agreed, ideally there would be a gentoo dev interested in that - but as long there's noone ...
+20:49 < Halcy0n@> Cardoe: it would be best so others could join the list and conversations.
+20:50 < Cardoe+> and publicly provide archives
+20:50 < dberkholz@> are there discussions happening on pms-bugs rather than just bugs posted to it?
+20:50 < Halcy0n@> dberkholz: that has been the case in the past, yes.
+20:52 < Cardoe+> Halcy0n: can you tell us the last e-mail across it?
+20:52 < Cardoe+> actually never mind
+20:53 < Cardoe+> Creating a mailing list I don't believe would be opposed (anyone opposing can PM me now) and would allow public transparency into the process and would allow for review of the process in the future so I think it's a plus moving forward.
+20:53 < Halcy0n@> Cardoe: its mostly been submitted patches.
+20:53 < Halcy0n@> And discussions of those patches.
+20:53 < Cardoe+> which sounds a bit like a ML already
+20:54 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080911-agenda.txt has the list of requirements i've collected
+20:54 < Halcy0n@> dberkholz: that looks good to me.
+20:55 < Calchan+> dberkholz, yes, looks good
+20:55 < Cardoe+> So from that list does anyone see any that would prevent you from voting yes today to the PMS as a draft standard for EAPI 0 and 1?
+20:55 < Cardoe+> I don't see any that would prevent me from voting yes today. Of course, I reserve the option to change that going forward since we are working with a live document.
+20:56 < Calchan+> Cardoe, yes, I don't see the point voting for something unfinished when we could vote for the same finished thing in 2 weeks
+20:56 < dberkholz@> by making it a draft standard, what we're saying is that it is now a requirement to resolve conflicts between it and package managers
+20:56 < dberkholz@> there's not much value in approving a spec that doesn't match reality
+20:57 < Cardoe+> correct
+20:57 < Cardoe+> I think we have 2 outstanding issues between Portage/pkgcore & PMS/Paludis
+20:58 < Cardoe+> Which can be a very good test to see how people will resolve this.
+20:59 < Halcy0n@> Alright, we are at the end, can we vote?
+20:59 < Calchan+> Halcy0n, yes
+20:59 < Calchan+> I mean, yes I can vote
+21:00 < Cardoe+> let's do it
+21:00 < dberkholz@> ok
+21:00 <dertobi123@> yep, let's vote
+21:00 < dberkholz@> do we want to specify that our acceptance is conditional upon those requirements being resolved?
+21:00 < Cardoe+> 3 choices..
+21:01 < Cardoe+> Yes, Yes conditional upon requirements being resolved, No
+21:01 < dberkholz@> i'm gonna go with #2.
+21:01 < Halcy0n@> I'm with #2 as well
+21:02 < Cardoe+> #2 here
+21:02 <dertobi123@> #2 too
+21:02 < Calchan+> I vot 3 in the present state
+21:02 <dertobi123@> being solved until the next meeting i'd suggest in addition
+21:02 < Calchan+> s/vot/vote/
+21:02 < dberkholz@> i agree w/ dertobi123 -- 2 weeks to resolve. there's nothing major there
+21:03 < Cardoe+> Do we want to vote on creating a ML now or let it be discussed on the ML first?
+21:03 <dertobi123@> creating that ML sounds like a logical thing to me, so vote and yes please
+21:03 < dberkholz@> i'm pretty sure that's what we just did. making a list was one of the reqs, and we just voted to accept given the reqs.
+21:04 < Halcy0n@> dberkholz: agreed. I have to run now.
+21:04 < dberkholz@> ok
+21:04 < Calchan+> thanks Halcy0n
+21:05 < dberkholz@> that's it for this meeting
+21:05 < Cardoe+> I agree with creating the ML
+21:05 < Calchan+> dberkholz, weren't we supposed to discuss eapi2 ?
+21:05 < dberkholz@> do people not read my posts?
+21:05 < dberkholz@> that kind of discussion is for lists, not meetings
+21:05 < dberkholz@> plus we hit our hourly limit
+21:06 < Calchan+> dberkholz, ah sorry, I understood we'd discuss it here
+21:06 < Cardoe+> dberkholz: The discussion was over.. the final list was submitted afaik
+21:06 < dberkholz@> there have been multiple replies on it today
+21:07 < dberkholz@> that just isn't enough time
+21:07 < dberkholz@> i'm happy to vote on it on -council though
+21:07 < dberkholz@> if not, we can vote it in 2 wks
+21:07 < Calchan+> somebody should reopen the channel then
+21:08 -!- mode/#gentoo-council [-m] by dberkholz
+21:08 < dberkholz@> meeting's over
+21:08 < dberkholz@> thanks for playing
+21:08 < dberkholz@> http://dev.gentoo.org/~dberkholz/20080911-agenda.txt has summary
diff --git a/meeting-logs/20080925-summary.txt b/meeting-logs/20080925-summary.txt
new file mode 100644
index 0000000..8eb3465
--- /dev/null
+++ b/meeting-logs/20080925-summary.txt
@@ -0,0 +1,53 @@
+Roll call
+=========
+betelgeuse here
+cardoe here [dang]
+dberkholz here
+dertobi123 here
+halcy0n here
+jokey here
+lu_zero slacker
+
+New topics
+==========
+
+EAPI-2
+------
+Goal: Vote on approval
+
+Requirements:
+
+ - 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.
+ - Let's tag the git repository something like
+ eapi-$EAPI-approved-$DATE.
+
+Result: EAPI=2 is approved.
+
+
+PROPERTIES in 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.
+
+
+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/meeting-logs/20080925.txt b/meeting-logs/20080925.txt
new file mode 100644
index 0000000..ad35fa7
--- /dev/null
+++ b/meeting-logs/20080925.txt
@@ -0,0 +1,213 @@
+20:00 < darksiide > ding!
+20:00 <Betelgeuse@> dong
+20:00 < ciaranm > the witch is dead
+20:02 < dberkholz@> who's here?
+20:02 < dberkholz@> lost track of time for a sec
+20:03 <Betelgeuse@> dberkholz: \o/
+20:03 <dertobi123@> <- here
+20:03 * Halcy0n is here
+20:03 < jokey@> plop
+20:03 < dang > <- is Cardoe today
+20:03 < jokey@> dang: oh, reincarnation? ;)
+20:03 < dang > jokey: More like astral projection...
+20:04 < dberkholz@> where's lu?
+20:04 -!- jokey changed the topic of #gentoo-council to: Next meeting: now
+20:06 < dberkholz@> ok, let's get started without him
+20:06 < dberkholz@> can someone try to contact him somehow?
+20:06 -!- mode/#gentoo-council [+v dang] by Halcy0n
+20:06 < dberkholz@> (and speak up so i know who you are)
+20:06 <Betelgeuse@> dberkholz: Shouldn't you have his number :D
+20:06 <Betelgeuse@> I can dig it out too of course.
+20:06 < dberkholz@> it would be nice for someone else to step up and do something occasionally..
+20:07 < dberkholz@> here's a brief agenda -- http://dev.gentoo.org/~dberkholz/20080925-agenda.txt
+20:08 < dberkholz@> so let's get rolling on eapi-2
+20:08 < dberkholz@> anyone not ready to vote?
+20:08 <Betelgeuse@> dberkholz: txt msg sent
+20:08 < Halcy0n@> I am ready.
+20:08 -!- thargor__ is now known as thargor
+20:08 < dberkholz@> as i mentioned before the meeting, i stuck a pdf at http://dev.gentoo.org/~dberkholz/pms/pms_eapi-2_no-kdebuild-1_20080925.pdf -- see the appendix
+20:09 <Betelgeuse@> So we would move a copy like that to the PMS project pages then?
+20:10 <Betelgeuse@> Or the html output generated for better linking from stuff like devmanual would work too.
+20:10 < dberkholz@> i'd like to just stick a tag in git
+20:10 < dang+> An html copy somewhere would be *really* nice.
+20:10 < jokey@> dberkholz++
+20:11 < jokey@> one of us should just add a gpg signed one there and be done with it
+20:11 < dberkholz@> putting a copy in the pms project space would make sense to me, so people have somewhere simple to get this info
+20:11 < dberkholz@> any pms folks can comment on that?
+20:11 < ciaranm > app-doc/pms
+20:11 < dang+> That's what I meant, of course. The official one could still be in git.
+20:11 < jokey@> maybe add a generated one to the project page as well so people don't need to install texlive just to take a look at it
+20:12 <dertobi123@> jokey: pdf and html (as dang suggested) would be nice, yeah
+20:12 < ciaranm > ferdy: ^^ you can do that, right?
+20:13 < dang+> and an app-doc/pms-2 for people who do want a local copy.
+20:13 < nirbheek > app-doc/pms-bin? :)
+20:13 < dang+> Heh.
+20:13 < ciaranm > dang: i was just going to merge the eapi-2 branch into master...
+20:14 < ciaranm > the only reason eapi 2 is on a branch just now is to avoid giving the impression it's been finalised
+20:14 < jokey@> anyway, nothing else required for vote, right? ;)
+20:14 < dang+> ciaranm: Sure, I have no problem with that.
+20:14 < dang+> But cutting a tarball, sticking it on the mirror, and having a pms-2 version in portage would be a nice touch.
+20:14 < dang+> Not required, but nice.
+20:15 < ciaranm > do we do a new tarball when we write some more of the EAPI 0 stuff, then?
+20:15 <Betelgeuse@> ciaranm: Well pms-2 would isntall the tag
+20:15 < dang+> Good question...
+20:15 <Betelgeuse@> ciaranm: if coming from git
+20:15 < dang+> tag may be better, I'd forgotten about that. :P
+20:15 < ciaranm > a tag doesn't really make sense to me
+20:16 < ciaranm > i mean, what'd it tag? the first eapi 2 commit? the last eapi 2 commit? the most recent eapi 2 related fix? the most recent fix that is some way relevant to eapi 2? and once it's there it's stuck
+20:16 <Betelgeuse@> ciaranm: For EAPI 0 of course not, but we aren't approving that atm.
+20:16 < Halcy0n@> So, can we vote? The specifics of what we do with PMS can be discussed separately.
+20:17 <dertobi123@> indeed
+20:17 < dang+> Fine with me.
+20:17 <Betelgeuse@> ciaranm: Well we can tie the ebuild to particular commits too.
+20:17 < Halcy0n@> So, yes from me.
+20:18 * Sput thinks people mean a branch rather than a tag
+20:18 <Betelgeuse@> ciaranm: And increase it as fixes come I guess.
+20:18 < ciaranm > Betelgeuse: so how's that different from just pointing the ebuild at master?
+20:18 <Betelgeuse@> ciaranm: council approval for changes
+20:18 <Betelgeuse@> ciaranm: if wanted
+20:18 < dberkholz@> if we approve one thing, the wording could later change so that it actually means something else
+20:19 * jokey is for it too
+20:19 < ciaranm > in which case the conflict resolution process kicks in
+20:19 < dang+> But a signed tag specifying what was actually the state at approval time would help a lot...
+20:20 < dang+> Just as a historical record, if nothing else.
+20:20 < dang+> Anyway, I vote to approve, too.
+20:20 < dberkholz@> i would like to see a tag that says something like eapi-$EAPI-approved-$DATE
+20:20 * jokey got a note that lu went to bed already
+20:20 < ciaranm > it would? *shrug* sign and tag away all you like. tags are cheap.
+20:20 < dberkholz@> but yes, i am also for eapi 2
+20:20 * dertobi1 is too
+20:20 <Betelgeuse@> +1
+20:20 < jokey@> ++
+20:21 < dberkholz@> who agrees with the tag?
+20:21 < Halcy0n@> Please tag it :)
+20:22 <Betelgeuse@> I do
+20:22 < dberkholz@> (btw, just to make it clear for the record, EAPI=2 is approved.)
+20:22 * dertobi1 agrees
+20:22 * jokey too
+20:22 * dang too
+20:23 < ciaranm > ok, someone please make a signed tag then and mail it to the list which doesn't exist yet
+20:23 < dberkholz@> is it merged to master already?
+20:23 < dang+> Heh.
+20:23 < ciaranm > is now!
+20:24 < dberkholz@> updated agenda/summary -- http://dev.gentoo.org/~dberkholz/20080925-agenda.txt
+20:24 < dberkholz@> please verify the EAPI=2 section
+20:25 < Halcy0n@> Sounds good to me Donnie.
+20:25 < dberkholz@> ok, let's move on to the next topic
+20:25 < dberkholz@> PROPERTIES in cache
+20:26 < jokey@> no need to approve cache changes imho as long as they don't break older versions of portage
+20:26 < dberkholz@> there were zero objections on-list
+20:26 * dang agreed with jokey
+20:26 * dertobi1 too
+20:26 < dberkholz@> yeah, that's my feeling
+20:26 <Betelgeuse@> cache changes should be needed because of tree wide changes which should go through us
+20:26 < Halcy0n@> Fine by me.
+20:26 <Betelgeuse@> not always of course
+20:27 <Betelgeuse@> So why not do both?
+20:27 < zmedico > the cache is a community asset
+20:27 < dberkholz@> cache changes aren't just needed because of changes to the tree, but because portage is just tracking more data
+20:27 < zmedico > so I don't really think it's all my decision
+20:28 < dberkholz@> that's why i think the ebuild PROPERTIES section is more relevant to us directly, because that part always impacts the tree
+20:28 < ciaranm > cache is an EAPI / PMS thing, and all sorts of third party apps rely upon it, so changing it isn't something to be done without proper discussion
+20:28 < zmedico > nod
+20:29 <Betelgeuse@> The council hasn't had that much technical stuff to decide any way so I don't see why we would need to cut down the list.
+20:30 < jokey@> ciaranm: that's why I added "as long as it doesn't break older stuff"
+20:30 < jokey@> if one just adds fields, it shouldn't be a real issue anywhere
+20:30 < dberkholz@> you can only cut down the list if something was on the list to start with ... cache changes have never gone through council in the past to my knowledge
+20:30 < ciaranm > that's not entirely true...
+20:30 < zmedico > note that there is currently an upper limit on the number of cache entries
+20:31 < zmedico > 22 max, 7 unused
+20:31 < zmedico > adding PROPERTIES leaves 6 unused
+20:31 < ciaranm > you can use things that are currently defined as unused without breaking things. you can't *add* without breaking portage
+20:31 < ciaranm > dberkholz: the last cache change was pre-council, wasn't it?
+20:32 < dberkholz@> i don't think so
+20:32 < ciaranm > wasn't the last cache change the addition of the EAPI field?
+20:32 < zmedico > last addition was EAPI
+20:32 < zmedico > few years back
+20:34 < dberkholz@> seems like if anything, this should be another issue that PM devs resolve amongst themselves and only present to council if they can't agree
+20:34 < dberkholz@> is there a lack of agreement?
+20:35 < ciaranm > there's no disagreement on PROPERTIES, just some of the proposed values for it
+20:35 < dberkholz@> ok
+20:36 < dberkholz@> do council people agree with what i said?
+20:36 < jokey@> sure
+20:36 <dertobi123@> yep
+20:36 * jokey notes a bunch of stuff falls into that category actually
+20:36 < dang+> Sure.
+20:36 <Betelgeuse@> the majority has spoken
+20:37 <Betelgeuse@> So let's go with that then.
+20:37 < jokey@> right
+20:37 < dberkholz@> ok, if you guys agree on PROPERTIES in cache, go for it.
+20:37 * ciaranm shall add it to pms
+20:38 < dberkholz@> let's move on to the PROPERTIES=interactive
+20:39 < remi` > quick question: PROPERTIES is added to which EAPI ?
+20:40 < ciaranm > remi`: PROPERTIES is retroactively added to 0, 1 and 2 with the restriction that it can't be used for anything that package managers can't safely ignore
+20:40 < remi` > great, thanks for the clarification
+20:41 < Halcy0n@> Are there any disagreements on having PROPERTIES=interactive from any of the PM people?
+20:41 < ciaranm > interactive was the one we didn't disagree on
+20:41 < dberkholz@> i'm presuming zmedico agrees with it too =)
+20:42 < zmedico > nod
+20:42 < dberkholz@> council members, do you think this is something that should require council approval?
+20:44 < Halcy0n@> I think it makes sense for us to approve it.
+20:44 <dertobi123@> i'm unsure, so it wouldn't hurt to approve it. i'm for it :)
+20:44 <Betelgeuse@> yes
+20:44 < jokey@> yes
+20:44 < jokey@> ;)
+20:44 < dberkholz@> to generalize, new global variables in ebuilds that are used by the PM
+20:45 < dang+> Probably a good idea.
+20:45 < jokey@> anything global imho
+20:45 < jokey@> so it expands to vars and functions
+20:45 < ciaranm > vars and functions would be an EAPI thing anyway
+20:46 < dberkholz@> unless they're optional again
+20:46 < dberkholz@> seems like an odd use case though
+20:46 < dberkholz@> pkg_pretend() anyone?
+20:46 < jokey@> eapi stuff
+20:47 < jokey@> so handled within pms group as usual
+20:47 < ciaranm > pkg_pretend is a lot easier if you can be sure it'll get used... so it's a lot easier as an EAPI thing...
+20:47 < dberkholz@> reasonable
+20:48 < dberkholz@> what we're saying is that new ebuild features that aren't covered by PMS/EAPIs still need to be approved by the council
+20:49 < jokey@> eh, isn't all this global ebuild stuff (to be) covered by pms?
+20:49 < ciaranm > there aren't going to be many things done that way, so it's probably easier to just send every new EAPI and every carefully done retroactive EAPI change to the council...
+20:50 <Betelgeuse@> indeed
+20:50 < jokey@> ++
+20:50 < dberkholz@> ciaranm: so you're classifying this as a retroactive EAPI change?
+20:51 < dberkholz@> i'm a bit underslept lately
+20:51 < ciaranm > dberkholz: PROPERTIES? yeah
+20:51 < ciaranm > PROPERTIES is an EAPI thing that we just happen to be able to get away with doing retroactively by carefully weasel wording it
+20:51 < dberkholz@> yeah, ok, that way we can just say it's just a standard pms/eapi thing and not deal with setting new policies and whatnot
+20:52 < dberkholz@> so let's move on to the approval vote
+20:52 < Halcy0n@> How are we determining which properties are allowed though? Is that tied to a particular EAPI at this point, or are you wording it up in such a way that new ones can be introduced at any time?
+20:53 < dberkholz@> since PROPERTIES handling is optional, i was assuming that support for any given value of it was also optional
+20:53 < Halcy0n@> I just wanted to make sure :)
+20:53 < dberkholz@> and any new value would require council approval the way we've said it
+20:53 < ciaranm > what dberkholz said
+20:53 < Halcy0n@> Okay, thanks.
+20:54 < Halcy0n@> I vote to approve it.
+20:54 < dberkholz@> so do i
+20:54 <Betelgeuse@> +1
+20:54 < dang+> ++
+20:55 < dberkholz@> ok, that's our agenda for today
+20:55 < dberkholz@> and right on time too!
+20:55 < Sput > nice work *clap*
+20:55 < Halcy0n@> Awesome. Thanks for getting everything organized Donnie.
+20:55 < dberkholz@> less so every week, as i get less and less sleep...
+20:55 < dberkholz@> adios, gotta run!
+20:56 < jokey@> ++
+20:56 <Betelgeuse@> I can make the tag.
+20:56 * jokey thinks donnie should get some choclate and cookies for free
+20:56 < ciaranm > Betelgeuse: do you know how to mail tags for git? i've never had to done that
+20:57 * dertobi1 hands donnie some swiss chocolate i bought in zurich yesterday :)
+20:57 < maekke > dertobi123: =)
+20:57 <Betelgeuse@> ciaranm: Hmm. True.
+20:58 <Betelgeuse@> ciaranm: I can try the normal way.
+20:58 < remi` > oh, I had one tiny question : when can we start using EAPI=2 in ~ and/or stable ebuilds ?
+20:58 <Betelgeuse@> remi`: You shouldn't commit something you haven't tested so after a pkg manager is committed with support for it
+20:58 <Betelgeuse@> remi`: zmedico probably does a release today
+20:58 < remi` > Betelgeuse, of course, but once portage is out, we can start using it?
+20:59 < ciaranm > paludis will probably be tomorrow, unless my laptop speeds up...
+20:59 <Betelgeuse@> remi`: yes
+20:59 < Caster > remi`: and in stable ebuilds when a portage that supports it is stable, I guess
+21:00 < ciaranm > zmedico / anyone else: please review the properties branch i just committed to pms
+21:00 < zmedico > sure
+21:01 < remi` > Betelgeuse, Caster, ok thanks
+21:02 <jmbsvicett > council: thanks for approving EAPI-2
+21:03 < zmedico > thanks for approving the PROPERTIES stuff too