Add the last 2 months of meetings. Also fix a typo in my nick from a summary I didn't add.

1 files changed, 310 insertions, 0 deletions

diff --git a/meeting-logs/20080828.txt b/meeting-logs/20080828.txt
new file mode 100644
index 0000000..b731ee8
--- /dev/null
+++ b/meeting-logs/20080828.txt
@@ -0,0 +1,310 @@
+19:56 < dberkholz@> are folks around?
+19:56 <   lu_zero@> \o/
+19:56 < dberkholz@> if it starts to get out of hand like last time, i'm gonna have to +m it.
+19:56 -!- Irssi: #gentoo-council: Total of 59 nicks [6 ops, 0 halfops, 0 voices, 53 normal]
+19:58 <Betelgeuse@> dberkholz: yes
+20:00  * dertobi1 is around
+20:00 < dberkholz@> ok, it's 2000
+20:00 -!- mode/#gentoo-council [+v Cardoe] by dberkholz
+20:01  *    jokey looks up
+20:01 < dberkholz@> Halcy0n: ping
+20:02 < dberkholz@> we've got 6, let's get started. hopefully he shows up in the next few min
+20:02 <   Halcy0n@> Present :)
+20:02 < dberkholz@> oops, never actually saw Cardoe respond
+20:03 <    Cardoe+> I'm here
+20:03 < dberkholz@> ok
+20:03 < dberkholz@> agenda's in /topic if anyone hasn't had a chance to look it over
+20:03 <    Cardoe+> Was just zoned out staring at the wall waiting for the meeting to begin :-D
+20:03 < dberkholz@> sorry for the delay in getting it out, i've got a lot on my mind
+20:04 < dberkholz@> (new baby showing up in a few days)
+20:04 <     jokey@> congrats ;)
+20:04 -!- dberkholz changed the topic of #gentoo-council to: Favor irc.gentoo.org alias in docs, etc
+20:04 <   lu_zero@> I think we are all fine with this
+20:04 < dberkholz@> so, folks on -dev pointed out that apparently freenode folks like when other domains point to them
+20:04 <   lu_zero@> (congrats btw)
+20:04 <   Halcy0n@> congrats :)
+20:04 <Betelgeuse@> dberkholz: congrulations/condolences
+20:05 < dberkholz@> heh, that's more accurate, no doubt.
+20:05 <   Halcy0n@> I think we are ready to vote on this one.
+20:05 <Betelgeuse@> yes
+20:05 < dberkholz@> yes
+20:05 <Betelgeuse@> and yes
+20:05 <dertobi123@> yes
+20:05 <    Cardoe+> I was ready last week.. ;)
+20:05 <    Cardoe+> yes
+20:06 <     jokey@> yes
+20:06 <     jokey@> :D
+20:06 <   Halcy0n@> yes
+20:06 < dberkholz@> cool
+20:06 -!- dberkholz changed the topic of #gentoo-council to: Why aren't fired developers banned from the channels where they displayed this behavior?
+20:07 <Betelgeuse@> I don't think banning is necessary if the behaviour in question was misusage of power.
+20:07 < dberkholz@> Halcy0n & dertobi123 already replied on -dev saying they think fired devs should be banned from that place
+20:07 <     jokey@> same here
+20:07 <   lu_zero@> +1
+20:07 < dberkholz@> my opinion is that devrel should decide
+20:07 <       spb > the obvious answer is that they should be banned from any place where they've shown behaviour that would get any normal person banned
+20:08 <Betelgeuse@> I agree with spb.
+20:08 < dberkholz@> and if anything, we should just say devrel (or whoever's in charge of a certain place) has the right to do so
+20:08 <       spb > and, therefore, not from any place where they haven't
+20:08 <   Halcy0n@> spb: I think that's what I was trying to say, if I didn't word it in that exact way. :)
+20:08 <    Cardoe+> dberkholz: as I suggested last week. empower devrel to make the proper decision and to create a policy on this.
+20:08 <       spb > given that, i don't really see what being fired has to do with it
+20:09 <   Calchan > I don't agree, they've shown inapropriate behavior, the place doens't matter, they could have done it anywhere
+20:09 < dberkholz@> that's beyond the scope of this topic, which is a bit more focused
+20:09 <dleverton_ > So now we're punishing people for what they "could" have done?
+20:10  * musikc|l is back
+20:11 <musikc|lap > "saying they think fired devs should be banned from that place" +1
+20:11 <    Cardoe+> dberkholz: so what's the formal question asked of the council.. cause why isn't something for the council to answer since the council doesn't do the banning
+20:11 <    Cardoe+> devrel does
+20:11 <musikc|lap > Calchan, do you think a fired dev should be banned from all channels? not sure i understand and want to clarify
+20:12 <    Cardoe+> so the question should be why don't we empower devrel to establish a policy and enforce it
+20:12 <      rane > devrel or userrel?
+20:12 <   Calchan > musikc|laptop, the problem is the behavior, not the channel
+20:12 <Betelgeuse@> Cardoe: I don't think we need to be handling fired devs any different from other users.
+20:12 <   antarus > Calchan: I disagree; the day the coucil says I have to ban a user from a channel I own is the day I resign
+20:12 <musikc|lap > Calchan, that makes sense but no one team has the authority unless council opts to grant it to control every #gentoo-*
+20:13 <Betelgeuse@> If our policies on banning users aren't clear then they can be improved.
+20:13 <    Cardoe+> Betelgeuse: and that policy is to have userrel have a policy and enforce it
+20:13 <   antarus > s/says/forces/
+20:13 <   antarus > they are free to make a compelling argument for a ban of course ;)
+20:13 <musikc|lap > Cardoe, i think it depends actually
+20:14 <musikc|lap > if the dev is being fired for a certain behavior such as inappropriate channel behavior, perhaps devrel is being asked why we dont automatically remove them from that channel, or as Calchan points out all channels.
+20:14 <musikc|lap > if its a former dev who later exhibits that behavior it's totally user rel
+20:14 <       spb > the most obvious response to which is that it's up to the channel owners who they allow in their channels
+20:15 <musikc|lap > spb, see my previous comment about how no one team has that authority currently
+20:15 <   ciaranm > in the same way that a gentoo developer spamming one irc channel is removed from all of freenode, you mean?
+20:15 <dleverton_ > musikc|laptop: the authority to let channel owners decide how to run their channels?
+20:15 < dberkholz@> this clearly has the potential to run forever, so let's set a 15-minute time limit on discussion here.
+20:15 < dberkholz@> starting now
+20:15 <musikc|lap > dleverton_, im merely stating that no one team has absolute authority in every channel
+20:15 <   Calchan > antarus, the question is should you own an official gentoo channel or should gentoo own it ?
+20:16 <musikc|lap > dberkholz, can you define if the question pertains to only certain channels or all?
+20:16 <   antarus > Calchan: perhaps gentoo should trust its developers to make good choices ;)
+20:16 <musikc|lap > Calchan, Gentoo owns it. when someone leaves the project the channel is handed over to another person, not left with ownership to the previous
+20:16 <       spb > Calchan: and gentoo's policy has long stated that individual teams and/or developers own and run their channels
+20:17 < dberkholz@> musikc|laptop: the question is pretty specific. it's just banning from the place where they showed that kind of behavior
+20:17 <musikc|lap > dberkholz, then perhaps we should stick to just that question for now.
+20:17 <       spb > dberkholz: in which case it's up to the channel owner to decide what sort of behaviour warrants a ban from that channel
+20:17 <       spb > that seems fairly obvious to me
+20:17 <musikc|lap > i agree that if the person is removed from gentoo for such behavior that we should remove them from that channel
+20:18 < dberkholz@> each irc channel isn't a separate organization, though. we're all part of gentoo
+20:18 <musikc|lap > dberkholz, so you want to change the question to apply to all channels then?
+20:18  * blackace doesn't see the issue, if they get fired for misbehaving somewhere they were probably removed from that somewhere before being fired, if they then misbehave somewhere else as a user, ban them from there, and so on...
+20:18 <       spb > and each channel is part of freenode, but we know enough to leave management of them to the channel owner
+20:18 < dberkholz@> i'm still trying to figure out the best way to go. i'm just making some points
+20:18 <      rane > it's unrealistic to ban a person in all #gentoo-* channels
+20:18 <dleverton_ > Can we define what exactly we mean by "channel"?  IRC, or more general?
+20:19 <musikc|lap > spb, a channel owner owns the channel as granted by Gentoo. otherwise it wouldnt be an official Gentoo channel
+20:19 < dberkholz@> more general for the whole topic -- a mailing list, the forums, etc
+20:20 <jmbsvicett > One point that has been raised is whether the council want to treat ex-devs differently from other users
+20:20 <jmbsvicett > If not, devrel doesn't deal with users.
+20:20 <     jokey@> the only difference is that they get auto+v in #-dev afaik
+20:20 <musikc|lap > jmbsvicetto, i think the topic is upon removing them, not later. if it's later then its definitely not a dev rel issue and they should be treated as any user
+20:21 <musikc|lap > jokey, devrel doesnt grant +V to everyone, first they must ask and second it must be approved
+20:21 <jmbsvicett > musikc|laptop: I understand. Another question is if we're talking about #gentoo-dev, #gentoo or specific projects channels
+20:21 <dertobi123@> dberkholz: i disagree, if this topic would be about lists, forums, #gentoo-* we're back at the "total ban from gentoo" discussion
+20:22 < dberkholz@> dertobi123: not really. it's just saying that banning from a specific place applies equally to a single irc channel or a single mailing list.
+20:22 <musikc|lap > jmbsvicetto, the question per dberkholz's explanation is for just #-dev but the discussion could include thoughts on all mediums and channels
+20:22 < dberkholz@> we're not at all addressing right now whether people should be additionally banned from other places
+20:23 <musikc|lap > council, so to the question at hand, only dberkholz and Halcy0n have shared their views. any others?
+20:23 < dberkholz@> dertobi123 did too, on list. =)
+20:23 <dertobi123@> yep
+20:24 <   lu_zero@> and I just said that I agreed
+20:24 <    Cardoe+> my opinion is that it should be up to devrel
+20:24 <dertobi123@> it's a logical step to ban someone from a place where he showed misbehaviour
+20:24  * musikc|l agrees
+20:24 <jmbsvicett > musikc|laptop: If it's #gentoo-dev, then I think it's up to devrel
+20:24 <dertobi123@> i don't see what needs to be discussed there besides the way of the how this if enforced
+20:25 <musikc|lap > dertobi123, how about enforced upon removal?
+20:25 <   Halcy0n@> I'm fine with just saying that this is up to devrel to decide on their policy and if someone wishes to question that policy, we address it at that point in time.
+20:26 <musikc|lap > Halcy0n, im ok with that. however id hope if someone wants to discuss a devrel policy they discuss it with ... you know... devrel first
+20:26 <dertobi123@> musikc|laptop: ack. it should be part of the retirement process from my pov (except when the person in question already has been banned from this places)
+20:26 <     jokey@> ++
+20:26 <musikc|lap > dertobi123, +1
+20:27 <    Cardoe+> seems like there's a reasonable consensus.... now on to technical things..
+20:28 <musikc|lap > agreed, ill work with rane and jmbsvicetto to hammer out any details from a devrel pov and we'll run it through the rest of devrel for feedback
+20:28 < dberkholz@> we haven't gotten agreement from a council majority on that
+20:28 < dberkholz@> that's me, Cardoe, Halcy0n 
+20:28 <musikc|lap > haha, sorry!
+20:29 < dberkholz@> lu_zero hasn't agreed & i'm not entirely clear on dertobi123 
+20:29 <musikc|lap > <Cardoe> my opinion is that it should be up to devrel
+20:29 < dberkholz@> Betelgeuse is probably eating popcorn
+20:29 <Betelgeuse@> :D
+20:29 <Betelgeuse@> I really should by some.
+20:29 <    Cardoe+> dberkholz: are you waiting on me?
+20:29 <   lu_zero@> dberkholz I consider it part of the retirement process
+20:29 < dberkholz@> Cardoe: nope
+20:30 < dberkholz@> lu_zero: ok, so you're fine with devrel deciding how to handle it?
+20:30 <musikc|lap > Cardoe, i was just posting your comment as it was the shortest one to sum it all up :)
+20:30 <   lu_zero@> dberkholz it's devrel task to retire people
+20:30 < dberkholz@> i'll take that as a yes
+20:30 <Betelgeuse@> I think it probably should be in the retirement process if the question is being retired due the continuing bad behaviour.
+20:31 <Betelgeuse@> s/probably//
+20:31 < dberkholz@> ok. now it indeed does seem that we've reached agreement
+20:31 < dberkholz@> right on time, too
+20:31 <musikc|lap > ;)
+20:31 <   lu_zero@> good
+20:32 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0: Conflict resolution
+20:32 <    fmccor > How far back does this go?  Would you ban someone fro #gentoo-dev, say, today for something that happened 2 years ago?
+20:33 <    fmccor > That strikes me as silly.
+20:33 < dberkholz@> devrel's making the policy
+20:33 < dberkholz@> discuss it amongst yourselves =)
+20:33 < dberkholz@> we're talking about EAPI 0
+20:33 <Betelgeuse@> fmccor: The retirement process is done for those people as far as I am concerned.
+20:34 < dberkholz@> ok, the main thing we came up with last meeting on PMS is figuring out how to handle conflict resolution
+20:34 <Betelgeuse@> I vote that we start voting on issues one by one.
+20:34 <   lu_zero@> ?
+20:34 < dberkholz@> i tossed some ideas into the agenda
+20:35 <Betelgeuse@> Bugzilla should work as a platform.
+20:35 < dberkholz@> Betelgeuse: "we" being council?
+20:35 <   ciaranm > i didn't see the promised "we'll mail the list with opinions" emails for this. where should i have been looking?
+20:35 <Betelgeuse@> dberkholz: yes
+20:35 <    Cardoe+> I had suggested (but not mentioned on the ML yet) that a 3rd party is appointed by the council to be the "merge master" to merge in changes to the PMS. When a conflict arises, the merge master will attempt to work with the parties involved and the issue resolved. If no resolution can be easily reached, the issue is referred to the council who will direct the merge master which way to go.
+20:35 < dberkholz@> ciaranm: yeah, that was full of fail.
+20:35 <   ciaranm > heh, fairy nuff
+20:36 < dberkholz@> i threw the idea i just thought of into the agenda
+20:36 < dberkholz@> which is asking PMS & portage devs to come up with a process for conflict resolution that they both agree to follow
+20:36 <   Halcy0n@> I think I hit all of the topics except this on the mailing list because I wanted to put some thought into it.  I have some ideas that I need to write up and I want to see discussed though.
+20:37 < dberkholz@> seems like everyone might be happier going along with a process you came up with yourselves
+20:37 <Betelgeuse@> dberkholz: but is that likely to happen?
+20:37 <   ciaranm > part of the problem with conflict resolution is what to do when portage makes non-EAPIed changes that break lots of existing packages
+20:37 < dberkholz@> and i tried to put some ideas out there for what that process might be
+20:37 < dberkholz@> but i think agreement has to begin with the involved people
+20:37 <       spb > ciaranm: you file a bug, and it gets marked WONTFIX
+20:37 <musikc|lap > ciaranm, wouldnt that not be part of the problem but the main reason being when any PM does that?
+20:37 <   lu_zero@> ciaranm do you have a list?
+20:38 < dberkholz@> we were talking about the list last meeting and wasted a lot of time on details that aren't relevant to us
+20:38 <   ciaranm > musikc|laptop: you could argue that, yes
+20:38 <   ciaranm > lu_zero: er, phase order changes and --jobs are the canonical examples
+20:38 <       spb > lu_zero: --jobs and phase ordering changes will do to start with
+20:38 <musikc|lap > ciaranm, just seems to be the basis for a need for a conf res
+20:38 <   lu_zero@> a list of ebuilds
+20:38 <   lu_zero@> anyway unrelated to the current topic
+20:39 < dberkholz@> ciaranm & spb: while you're here, do you have any good ideas for the resolution process?
+20:39 <Betelgeuse@> lu_zero: It's not totally unrelated.
+20:39 <   ciaranm > dberkholz: i've yet to get anything out of zac that isn't "i'll do whatever i want with portage, even if it breaks existing ebuilds and even if it goes completely against the gentoo documentation"
+20:39 <dleverton_ > lu_zero: no-one can know which ebuilds are broken without carefully examining the entire tree.
+20:40 <       spb > dberkholz: the most obvious is if some person can be found with enough knowledge of the problems in question to act as a sensible arbitrator
+20:40 <   ciaranm > dberkholz: really, "throw anything we can't agree upon to the council" would be fine, if i get assurances that the council will override zac if he does something stupid, and that the council will step in if zac decides to ignore PMS anyway on something the council's decided upon
+20:40 <Betelgeuse@> ciaranm: I am willing to do that.
+20:40 <       spb > unfortunately most such people that i can think of are already working on pms, so the next option is just to refer disputes to the council
+20:41 < dberkholz@> ok, basically the first two mentioned in the agenda
+20:41 <   ciaranm > the problem with resolving conflicts is that anything we do currently that isn't "whatever zac says, even if it means breaking lots of existing packages" gets turned into "pms has to document what portage does, for some random version of portage that most people aren't using"
+20:41 <   ciaranm > which i don't see as being a sensible way of getting things done
+20:41 <       spb > even when that contradicts the version of portage that people are using
+20:42 <musikc|lap > dberkholz, it seems that the suggestion of neutral third party for PMS sounds sane since ciaranm continually points out his concerns with working with zac
+20:42 < dberkholz@> yes, we clearly need zac, genone, and anyone else to buy into whatever the process is
+20:42 <   ciaranm > do we even need a neutral third party? the volume of things where there are conflicts is probably low enough not to overload the council
+20:42 <Betelgeuse@> musikc|laptop: I don't really see how a gentoo dev would be totally neutral.
+20:42 <   ciaranm > it'll give you a technical topic to discuss every other month or so if nothing else :P
+20:42 <     ferdy > musikc|laptop: how does a 'neutral' (who decides upon neutrality?) person help there?
+20:43 <   ciaranm > also, if we had a neutral person to spare, their time could be better spent contributing content
+20:43 < dberkholz@> i agree, actually. i think the council is a pretty reasonable group to do this
+20:43 <   lu_zero@> looks like at least some like the idea to have the council handle conflicts
+20:44 <musikc|lap > what about having non PM's work on the PMS doc so it reflects the opinions of the community?
+20:44 <   ciaranm > make that "have the council handle conflicts if the pms editors can't sort it out"
+20:44 <   lu_zero@> zmedico and ferringb is that ok for you as well?
+20:44 <   ciaranm > musikc|laptop: there shouldn't be opinion in pms
+20:44 <   zmedico > lu_zero: seems fair enough to me
+20:44 <musikc|lap > ciaranm, a standard is a collection of opinions put to 'law' as it were
+20:44 <   ciaranm > musikc|laptop: and we've never rejected a patch (except "resend with this fixed", which has always happened) from non PM people
+20:44 <       spb > musikc|laptop: frankly, the opinion of the community is irrelevant to a purely technical document
+20:44 <musikc|lap > spb, depends on who the community is imo
+20:45 <       spb > it documents existing behaviour
+20:45 <       spb > there's no room for opinion in that
+20:45 <   ciaranm > the problem with asking the community is that people say what they think *should* happen, which isn't what pms is dealing with
+20:45 <musikc|lap > spb, if it documents existing behavior then existing behavior of which PM?
+20:45 <   ciaranm > pms has to deal with what *does* happen wherever possible
+20:45 <  ferringb > lu_zero: what, punting up to council?
+20:45 < dberkholz@> ferringb: yeah
+20:46 <   ciaranm > what *should* happen is "future EAPI" territory
+20:46 <       spb > musikc|laptop: the best compromise that can be made between all vaguely recent portage versions and the tree
+20:46 <  ferringb > dberkholz: not sure you'll like the volume, going by past disagreements tbh.  things may've changed (these days I stay out of orbit) however.
+20:46 < dberkholz@> zmedico, ferringb, ciaranm, spb: so you'll all agree to follow council decisions on conflicts you aren't able to resolve otherwise?
+20:46 <       spb > where vaguely recent means "is likely to be in use by someone somewhere, or was stable some time in the last six months to a year"
+20:46 <   zmedico > dberkholz: I agree
+20:47 <  ferringb > dberkholz: either way, game to attempt something different- what's in place doesn't particularly work imo
+20:47 <   lu_zero@> ferringb do you have alternative proposals?
+20:47 <   ciaranm > dberkholz: so long as the council's prepared to follow through with its resolutions
+20:47 <   ciaranm > ferringb: please provide a list of patches of yours that we've rejected
+20:48 <musikc|lap > ciaranm, or could you provide a list of packages you accepted? might be just as easy :)
+20:48 <musikc|lap > s/packages/patches
+20:49 <       spb > that's only meaningful when compared to the list of patches that were submitted
+20:49 <Betelgeuse@> musikc|laptop: I can say for myself that I havent' had problems getting my patches in.
+20:49 <  ferringb > ciaranm: past discussions
+20:49 <   ciaranm > musikc|laptop: we've accepted (sometimes after asking for revisions) every patch that's been sent
+20:49 <  ferringb > ciaranm: not much point in pushing a patch up if it's already estabilished it has zero chance of getting in w/ folk in control.
+20:49 <musikc|lap > ciaranm, just saying either party could validate
+20:49 < dberkholz@> ok
+20:49 <   ciaranm > musikc|laptop: well, i've rejected exactly zero of ferringb's contributions so far
+20:49 <  ferringb > either way, council as arbitrator flies.
+20:50  * ferringb sighs; now we're getting into word play re: definition of 'contributions'
+20:50 <   lu_zero@> looks like this topic could be voted on
+20:50 <     jokey@> better do not do it here and now
+20:50 <     jokey@> lu_zero++
+20:50 < dberkholz@> ok, we've gotten people from all the groups to buy in
+20:51 < dberkholz@> it's definitely worth trying something new, and if this doesn't work, we can try to make the whole neutral person thing work
+20:51 < dberkholz@> i'm for it
+20:51 <dertobi123@> let's give it a try and see if that process works
+20:51 <dertobi123@> so yes
+20:52 <   lu_zero@> anybody against?
+20:52 <musikc|lap > so council will vote on any conflicts that arise from the PMS not being followed?
+20:52 <    Cardoe+> might as well just do a formal yes so no one says someone was asleep at the wheel.
+20:52 <   ciaranm > does this also mean we're taking pms as being definitive except where there're disagreements? which was the original question, really
+20:53  * ferringb notes management of pms vs it being definitive are two seperate questions
+20:53 <jmbsvicett > If that's the case, then perhaps it would be a good idea to have people mail their disagreements so they can be worked out
+20:53 < dberkholz@> you're right, that was the original question
+20:54 <musikc|lap > ferringb, yes that makes sense to me as well
+20:54 <    Cardoe+> ciaranm: I'd say yes
+20:54 <   lu_zero@> but isn't what's on topic...
+20:54 <       spb > ferringb: and when the original question was put to the council last time around, the answer that i can recall was that what still needed sorting out was a conflict resolution method
+20:54 <musikc|lap > we're well past the 15 minutes, will council be voting on the conf res process or should that wait 2 weeks?
+20:54 <   lu_zero@> could we just close one and move to the other ^^?
+20:54 <Betelgeuse@> Cardoe: yes
+20:54 < dberkholz@> ok. conflict resolution is handled
+20:55 -!- dberkholz changed the topic of #gentoo-council to: PMS as a draft standard of EAPI 0: Other issues?
+20:55 <musikc|lap > dberkholz, not to be confused with management of PMS as ferringb pointed out?
+20:55 < dberkholz@> we have about 5 minutes, so just bring up anything that's holding it back and we won't try to discuss it now
+20:56 <musikc|lap > i dont think anyone agrees, or if so i apologize for forgetting, that it is good to have a package manager standard. just how that is managed seems to be in disagreement.
+20:56 <  ferringb > musikc|laptop: think you screwed up your phrasing there
+20:56 <   zmedico > s/agrees/disagrees/
+20:56 <musikc|lap > hahah
+20:56 <musikc|lap > yes and yes
+20:57 < dberkholz@> so ferringb & zmedico think having a standard is worthwhile. that's accurate, yes?
+20:57 <  ferringb > dberkholz: I'd add a few adjectives in there, but yes
+20:57 < dberkholz@> and by standard i mean a written spec
+20:57 <   zmedico > yes, it's useful
+20:58 < dberkholz@> since we've had some vague discussions in the past about that, so i'm glad all the relevant people are on the same page
+20:58 <   lu_zero@> still I have concern of the form of the spec
+20:58 <   ciaranm > lu_zero: specifics please?
+20:58 <   lu_zero@> ciaranm in short?
+20:58 <   ciaranm > lu_zero: something concrete so i can say either "yes, we can improve that" or explain why i think it's correct the way it is
+20:58 <   lu_zero@> an article/scientific paper isn't a spec, an rfc comes closer
+20:59 <   Halcy0n@> We are about to hit 5pm, and I have a meeting right now (at work), so I must run.
+20:59 <   ciaranm > the reason we're not writing it to rfc standards is that we don't have the manpower to produce a loophole-free spec
+20:59 <   ciaranm > i'd take patches to rephrase individual sections to be more watertight if people think they can do it
+20:59 <musikc|lap > dberkholz, meeting officially wraps up on the hour, correct?
+21:00 < dberkholz@> zmedico, ferringb: i'd really love to see emails from you and any other PM developers describing what you think about PMS being a draft standard of EAPI 0.
+21:00 <   ciaranm > but producing a spec that can't be deliberately misinterpreted would take a hell of a lot longer than producing one that assumes a sensible and cooperative reader
+21:00 <       spb > and there's little point making it utterly free from loopholes when there's a well defined process for handling disagreements
+21:00 <   lu_zero@> ciaranm I recall I asked abnf sections
+21:00 < dberkholz@> we need to wrap up now
+21:00 <   ciaranm > lu_zero: abnf ends up being less readable than the written form
+21:00 <NeddySeago > ciaranm there is no such thing as a loophole-free spec, someone sometime will always find a meaning that was not intended
+21:00 <   lu_zero@> but is machine parsable
+21:01 <   lu_zero@> and it's quite easy get a checker out of it
+21:01 < dberkholz@> zmedico, ferringb: there's already the existing thread on gentoo-dev for the last council meeting, so you can just reply there
+21:01 <   ciaranm > NeddySeagoon: 'loophole-free' is what ISO aims for
+21:01 <       spb > NeddySeagoon: which is precisely why we're not trying to write one
+21:01 <NeddySeago > ciaranm Yep ... its a good aim
+21:01 <   ciaranm > lu_zero: the problem is, a grammar for specs ends up being very very horrid
+21:01  * musikc|l also has a RL meeting now
+21:01 <   lu_zero@> ciaranm rfc2234 isn't _THAT_ ugly
+21:01 <musikc|lap > verifying this one is done?
+21:01 <    Cardoe+> now we're arguing semantics
+21:02 < dberkholz@> it's past 2100, so the meeting is over. everyone with a stake in the spec really needs to email -dev about any issues with it becoming a draft standard
+21:02 <  ferringb > dberkholz: presume 2 week window or so?
+21:02 <   ciaranm > lu_zero: try, say, iso c++ draft n2723 section 14.7 if you want an example of just how bad formal specs get
+21:02 < dberkholz@> we'll resume at the next meeting and approve it unless there are objections between now and then
+21:02 <jmbsvicett > If there's an agreement about EAPI-2 in the mls prior to the next council meeting, will you be willing to vote on it?
+21:02 < dberkholz@> that'll be ... sept 11