dberkholz 08/09/28 15:55:45
Added: 20080814-summary.txt 20080814.txt
20080828-summary.txt 20080828.txt
20080911-summary.txt 20080911.txt
20080925-summary.txt 20080925.txt
Log:
Add the last 2 months of meetings. Also fix a typo in my nick from a summary I didn't add.
Revision Changes Path
1.1 xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080814-summary.txt?rev=1.1&content-type=text/plain
Index: 20080814-summary.txt
===================================================================
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.
1.1 xml/htdocs/proj/en/council/meeting-logs/20080814.txt
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080814.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080814.txt?rev=1.1&content-type=text/plain
Index: 20080814.txt
===================================================================
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
1.1 xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080828-summary.txt?rev=1.1&content-type=text/plain
Index: 20080828-summary.txt
===================================================================
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.
1.1 xml/htdocs/proj/en/council/meeting-logs/20080828.txt
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080828.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080828.txt?rev=1.1&content-type=text/plain
Index: 20080828.txt
===================================================================
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
1.1 xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080911-summary.txt?rev=1.1&content-type=text/plain
Index: 20080911-summary.txt
===================================================================
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.
1.1 xml/htdocs/proj/en/council/meeting-logs/20080911.txt
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080911.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080911.txt?rev=1.1&content-type=text/plain
Index: 20080911.txt
===================================================================
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
1.1 xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080925-summary.txt?rev=1.1&content-type=text/plain
Index: 20080925-summary.txt
===================================================================
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.
1.1 xml/htdocs/proj/en/council/meeting-logs/20080925.txt
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080925.txt?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/council/meeting-logs/20080925.txt?rev=1.1&content-type=text/plain
Index: 20080925.txt
===================================================================
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
|
