path: root/meeting-logs/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