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 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 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 yes 20:05 < dberkholz@> yes 20:05 and yes 20:05 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 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 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 So now we're punishing people for what they "could" have done? 20:10 * musikc|l is back 20:11 "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 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 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 Calchan, that makes sense but no one team has the authority unless council opts to grant it to control every #gentoo-* 20:13 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 Cardoe, i think it depends actually 20:14 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 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 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 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 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 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 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 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 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 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 Can we define what exactly we mean by "channel"? IRC, or more general? 20:19 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 One point that has been raised is whether the council want to treat ex-devs differently from other users 20:20 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 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 jokey, devrel doesnt grant +V to everyone, first they must ask and second it must be approved 20:21 musikc|laptop: I understand. Another question is if we're talking about #gentoo-dev, #gentoo or specific projects channels 20:21 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 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 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 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 it's a logical step to ban someone from a place where he showed misbehaviour 20:24 * musikc|l agrees 20:24 musikc|laptop: If it's #gentoo-dev, then I think it's up to devrel 20:24 i don't see what needs to be discussed there besides the way of the how this if enforced 20:25 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 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 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 dertobi123, +1 20:27 < Cardoe+> seems like there's a reasonable consensus.... now on to technical things.. 20:28 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 haha, sorry! 20:29 < dberkholz@> lu_zero hasn't agreed & i'm not entirely clear on dertobi123 20:29 my opinion is that it should be up to devrel 20:29 < dberkholz@> Betelgeuse is probably eating popcorn 20:29 :D 20:29 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 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 I think it probably should be in the retirement process if the question is being retired due the continuing bad behaviour. 20:31 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 ;) 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 ciaranm, or could you provide a list of packages you accepted? might be just as easy :) 20:48 s/packages/patches 20:49 < spb > that's only meaningful when compared to the list of patches that were submitted 20:49 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 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 let's give it a try and see if that process works 20:51 so yes 20:52 < lu_zero@> anybody against? 20:52 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 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 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 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 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 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 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 hahah 20:56 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 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 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 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 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 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