path: root/meeting-logs/20111108.txt

20:00 <@ulm> O.K., let's start
20:00 <@ulm> roll call
20:01  * hwoarang here
20:02 <@ulm> Betelgeuse, chainsaw, dberkholz, grobian, jmbsvicetto?
20:02 <@grobian> here
20:02 <@grobian> sorry
20:02 <@grobian> connection is very flacky
20:03 <+dberkholz> 18:59 < dberkholz+> Calchan is gonna proxy for me at tuesday's meeting
20:03 <+dberkholz> i'm leaving for the airport in a few minutes
20:03 <@ulm> k
20:03 <+dberkholz> in case he doesn't pop his head up for any reason, i'll go for identical msgs and on the api issue, at least a 90-day wait before breakage, or no breakage at all
20:03 <@jmbsvicetto> pong
20:04 <@jmbsvicetto> here
20:04 <@jmbsvicetto> ulm: Do you need me to call anyone?
20:04 <@ulm> jmbsvicetto: betelgeuse, calchan, and chainsaw are still missing
20:06 <@ulm> !seen chainsaw
20:06 < willikins> ulm: Chainsaw was last seen 2 hours, 51 minutes and 55 seconds ago, quitting IRC (Quit: Leaving) and a moment before saying "idella4: I'm afraid we can't let users run the entire show though. See what Zorry thinks." in #gentoo-dev
20:06 <@ulm> anyway, who's logging?
20:06 <@jmbsvicetto> ulm: give me a minute and I'll call Petteri and Tony
20:08  * Betelgeuse fails
20:08 <@jmbsvicetto> Betelgeuse should be around in a minute
20:10 <@jmbsvicetto> calling chainsaw
20:11 -!- Chainsaw [~chainsaw@gentoo/developer/atheme.member.chainsaw] has joined #gentoo-council
20:11 -!- mode/#gentoo-council [+o Chainsaw] by ChanServ
20:11  * Chainsaw salutes jmbsvicetto 
20:11 < Calchan> sorry, got delayed in a meeting
20:11 <@jmbsvicetto> Heya Tony :)
20:12 <@ulm> so Calchan (dberkholz's proxy) still missing, but let's start
20:12 <+dberkholz> ulm: look up 2 lines =P
20:12 <+dberkholz> Calchan: ok, i'll tag off with you then.
20:12 <@ulm> oops, sorry
20:12 <@ulm> all there
20:12 <@ulm> who's logging?
20:12 <@jmbsvicetto> ulm: I have logs
20:13 <@ulm> First topic: ChangeLog and commit messages
20:13 <@ulm> Do we require identical ChangeLog entries and commit messages?
20:13 <@grobian> no
20:14 <@jmbsvicetto> no
20:14 <@ulm> no
20:15 <@hwoarang> makes no sense so no
20:15 < Calchan> it would be a yes from here
20:15 <@Chainsaw> No
20:15 <@jmbsvicetto> but it's up to the developer using different messages to ensure the messages are appropriate. So using the ability to have different messages to write "stupid messages" on ChangeLogs is not ok
20:15 <@grobian> obviously
20:15 <@Chainsaw> If I correct a spelling error in a Changelog, the commit message should be "fixing typo balh -> blah".
20:15 <@Chainsaw> Not the whole message again.
20:15 <@ulm> Betelgeuse?
20:16 <@Betelgeuse> ulm: I agree with Chainsaw that it shouldn't be a strict rule. Preferred whenever it makes sense.
20:16 <@ulm> jmbsvicetto: I think everybody agrees on that
20:17 <@jmbsvicetto> ulm: It seems it's best we make it clear
20:18 <@ulm> hm, how about "it's recommended to use the same message for changelog and as commit message"?
20:18 <@grobian> recommended fine with me, basically what repoman commit now does
20:18 <@jmbsvicetto> ulm: sorry, what I meant was that it was best we made a comment like I did above so there's no doubt about our goal
20:19 <@ulm> anyone can come up with a good wording?
20:19 <@jmbsvicetto> ulm: I'm fine with stating as recommended or just adding a note that developers are still responsible for the messages used and that we still expect changelogs to have appropriate messages
20:19 <@grobian> usual rules on writing useful changelog and commit messages apply?
20:19 <@jmbsvicetto> grobian: seems good to me
20:20 <@grobian> s/useful/appropriate/
20:20 <@ulm> grobian: yes, I think that's fine
20:20 <@grobian> I like that more
20:20 < Calchan> ulm, "Please use the same commit and Changelog message whenever you do not have a strong reason of doing otherwise" how's that?
20:20 <@ulm> and short ;)
20:20 <@grobian> Calchan: that's a different message, IMO
20:21 <@grobian> I have no problem with people doing ugly [myebuild] version bump commit messages, while  having "Version bump." as changelog message
20:21 < Calchan> grobian, I was just suggesting at ulm's request, anything else is good with me if it's good with you
20:21 <@jmbsvicetto> Calchan: one could argue that would still allow to use the "ignore this" messages for changelog.
20:22 <@grobian> Calchan: of course, was just explaining my opposal ;)
20:22 <@ulm> So, "Usual rules on writing appropriate ChangeLog and commit messages apply."?
20:22 <@grobian> it's off-topic, but basically we want to repeat that we want to see appropriate messages being used
20:22 <@grobian> ulm: +1
20:22 <@ulm> Can everyone live with this?
20:23 < Calchan> ulm, wfm
20:23 <@Betelgeuse> I would rather spell out what "Usual rules" mean
20:23 <@ulm> Betelgeuse: Then suggest a wording. ;)
20:24 < Calchan> or point/link to them
20:24 <@grobian> Betelgeuse: as long as we avoid "common sense", since that seems not to be a shared thing
20:24 <@jmbsvicetto> what about: "developers are free to use different messages for ChangeLog and commit, but they're responsible for the messages used and the council still expects appropriate messages to be used" ?
20:25 <@grobian> + for both
20:25 <@grobian> ?
20:25 <@Betelgeuse> http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
20:25 <@Betelgeuse> and jmbsvicetto's wording is fine
20:25 <@grobian> ohw, nice page
20:26 <@ulm> +1 for jmbsvicetto's wording
20:26 < Calchan> jmbsvicetto, I like the fact that this rules out the fact that devrel may be involved in such situations, not entirely sure it's a good thing though
20:26 <@grobian> Can we add Betelgeuse's link to that blub too?
20:26 <@ulm> grobian: yep
20:27 <@jmbsvicetto> +1 on adding the link
20:27 <@grobian> ok, jmbsvicetto's + Betelgeuse's link for me then
20:27 <@grobian> :)
20:28 <@ulm> o.k., that's 4 out of 7 at least
20:28 <@ulm> next topic?
20:28 <@grobian> ok
20:29 <@jmbsvicetto> sure
20:29 <@ulm> Eclasses policy
20:29 <@ulm> Are developers allowed to remove functions from eclasses, or change the API in general?
20:29 <@ulm> http://archives.gentoo.org/gentoo-project/msg_87aecc20ce7030e321ab2db6c90f36cc.xml
20:30 <@grobian> I tend to think the gx86 tree should be fine with it, we cannot really take all existing overlays into account
20:30 < Calchan> not without reasonable warning time, eg 90 days
20:30 <@Betelgeuse> I don't know if you noticed but vapier has been doing it with less than a days notice
20:30 <@grobian> I'd suggest normal 30 days warning
20:31 <@hwoarang> if nobody uses them what is the problem?
20:31 <@grobian> sure, but if there are no consumers, why not remove some thing?
20:31 < Calchan> hwoarang, overlays may still be using them
20:31 <@ulm> grobian: Plus posting the diff to -dev ML
20:31 <@grobian> ulm: agreed
20:31 <@jmbsvicetto> I think we shouldn't make things harder than needed, so we should be able to change API. A reasonable advanced notice is desirable, though. I'd say 30 or 60 days
20:31 <@hwoarang> Calchan: i thought we do not support overlays
20:31 <@grobian> ulm: for removal, I guess a diff isn't strictly useful
20:31 <@hwoarang> as in, we only have control over the gx86
20:31 <@Betelgeuse> There is no reason to break overalys for no benefit
20:32 < Calchan> grobian, you're not talking about a single package here, but about an eclas which may be used by multiple packages, and 30 days may not be enough to fix thm all
20:32 <@ulm> grobian: I was thinking about API changes in general
20:32 <@ulm> what's the waiting period for eclass removal?
20:32 < Calchan> hwoarang, whether we support them or not they do exist and we may not want to anger our community more than reasonnable
20:32 <@grobian> ulm: ok, might make sense, but that's close to -dev review of all changes to eclasses
20:32 <@ulm> can someone remind me please?
20:32 <@jmbsvicetto> hwoarang: we should give overlay mantainers a chance to react to changes in eclasses
20:32 <@grobian> Calchan: grep is your friend
20:33 <@Betelgeuse> ulm: http://devmanual.gentoo.org/eclass-writing/index.html
20:33 <@Betelgeuse> ulm: 30 days
20:33 < Calchan> grobian, tools don't matter in this discussion
20:33 <@grobian> copy the eclass to your overlay
20:33 <@grobian> I think a notice, 30 days makes sense
20:33 <@grobian> ebuilds disappear to
20:33 <@grobian> sometimes entire ranges (KDE)
20:34 <@jmbsvicetto> Calchan: when dealing with substantial changes to eclasses, it's probably a better idea to "bump" the eclass.
20:34 <@Betelgeuse> grobian: shadowing eclasses are a bad thing
20:34 <@ulm> 30 days for API change should be sufficient, if it's sufficient for eclass removal
20:34 <@grobian> Betelgeuse: tell me… but well, if you don't want to fix your ebuilds...
20:34 <@Betelgeuse> grobian: they tend to get oudated and users won't get bug fixes etc
20:34 < Calchan> jmbsvicetto, then it's a different eclass, what we are talking about right now is changing the API of a given one
20:34 <@jmbsvicetto> Betelgeuse: but it might be simpler to copy an eclass to an overlay while updating the ebuilds to the new eclass
20:35 <@grobian> So, who is concerned about overlays here?
20:35 <@jmbsvicetto> Calchan: sure
20:35 <@hwoarang> i am not
20:35 <@grobian> me neither
20:35 <@jmbsvicetto> grobian: me, in the sense we should give sufficient advanced notice to overlay maintainers
20:35 <@Betelgeuse> grobian: to a degree
20:35 < Calchan> I think a warning period and adding an ewarn in the changed function so that users/devs notice the change is the right thing to do
20:36 <@grobian> I do agree with a notice
20:36 <@grobian> Calchan: can agre with that
20:36 < Calchan> and 30 days is too short for an eclass imo
20:36 <@jmbsvicetto> Calchan: the problem with that are the QA notices (the python eclass used that for a while)
20:36 <@grobian> prefer even
20:36 < Calchan> jmbsvicetto, can you expand a bit?
20:36 <@grobian> it's horror on rsync0
20:37 < Calchan> jmbsvicetto, oh yes I know what you mean
20:37 <@jmbsvicetto> Calchan: we want eclass maintainers to provide a warning to ebuild / overlay maintainers, but we might not like for them to have eclasses throw tons of QA warnings on every minor change
20:37 < Calchan> jmbsvicetto, but that's an entirely different issue, of an incompetent/non-cooperative dev
20:37 <@jmbsvicetto> Calchan: I know. I just wanted to be "clear"
20:37 < Calchan> you don't have to be stupid about it
20:38 <@jmbsvicetto> that's the problem with "common sense" not being enough - we sometimes have to say "too much"
20:38 <@grobian> :(
20:38 < Calchan> talking helps a lot in these case, you just have to be willing to do it
20:39 <@hwoarang> somehow developement has been evolved in a strict set of rules for the past 2 years
20:39 < Calchan> because we are socially lazy
20:39 <@hwoarang> not sure if we follow the right path
20:39 <@jmbsvicetto> so, I think we all agreed about requiring notification, we haven't agreed about how long it should be, though
20:39 <@hwoarang> you take away all the fun with so many ruls
20:39 <@hwoarang> *rules
20:39 <@ulm> hwoarang: blame the ones that stretch common sense
20:39 <@hwoarang> and you will keep devrel buzy in the near future
20:40 <@Betelgeuse> hwoarang: the standing practise btw is that you shouldn't do it
20:40 <@Betelgeuse> people just started doing it and no-one complained
20:40 <@Chainsaw> 30 days is definitely too short. Let's triple it. 90 days?
20:40 <@Betelgeuse> besides me any way
20:40 <@hwoarang> so you add more rules
20:40 < Calchan> Chainsaw, yes
20:40 <@hwoarang> because you can't control these people?
20:40 <@Chainsaw> I agree that overlays can't hold you back forever.
20:40 <@hwoarang> smart :)
20:40 <@Chainsaw> But some notice seems a fair thing to do.
20:40 <@Betelgeuse> hwoarang: so throw them out then?
20:40 <@grobian> eclass function drop == last rite ebuild == 30 days
20:40 <@Betelgeuse> hwoarang: or accept that people can do whatever they want?
20:41 <@jmbsvicetto> I believe 90 days is too long. I'd argue for 30 or 60 days
20:41 <@hwoarang> what is the point make 98% of devs "suffer" because of your rules
20:41 <@hwoarang> instead of kick problematic devs out?
20:41 < Calchan> Chainsaw, let's word it as "whenever possible"
20:41 <@hwoarang> *making
20:41 <@Chainsaw> jmbsvicetto: In that case I would prefer 60 over 30, yes.
20:41 <@ulm> if 30 days are sufficient for removing an eclasss, it should be sufficient for removal of a function
20:41 <@grobian> hwoarang: that 2% need those rules to act "common" instead of kicking them out?
20:41 <@Betelgeuse> ulm: 30 days from the point when nothing uses it any more
20:41 <@ulm> otherwise people will remove and re-add the eclass :p
20:41 <@Betelgeuse> ulm: so it has taken a while to get there
20:42 <@grobian> Betelgeuse: how can you know?  You shouldn't drop a function that's in use in gx86, obviously
20:42 <@jmbsvicetto> I'm sorry for my comment about "common sense". May I suggest we continue with this discussion and return to the "common sense" / "rules" discussion later (if needed)?
20:42 <@hwoarang> it seems to me that we keep voting +2 rules on every meeting
20:42 <@hwoarang> anyway
20:42 <@Betelgeuse> hwoarang: My general point was that we are changing a rule to more closely match what peole are doing
20:42 < Calchan> jmbsvicetto, what's the cost of keeping a function in an eclass for 90 days?
20:42 <@Betelgeuse> hwoarang: Feel free to suggest no rules about it.
20:43 <@Betelgeuse> grobian: It's more likely faster to adjust things in this case.
20:43 <@grobian> eclass removal time should be equal at least to eclass function removal
20:43 <@hwoarang> i did not say no rules. I say trust the devs and spank those you fail to behave
20:43 <@hwoarang> *who
20:43 <@Chainsaw> grobian: That is correct. In that case 30 everywhere. If it is felt that this is too short, I'm sure it will be tabled again.
20:43 <@jmbsvicetto> Calchan: we're talking about API changes, so it's not just about keeping a function. What about changing a function spec? Or requiring calling pkg_setup where it wasn't needed before
20:43 <@grobian> if 30 is too short, we need to up the limit for all of them
20:44 <@Chainsaw> grobian: (Shame though, I do think eclass work should be double or triple what ebuild work requires)
20:44 <@Chainsaw> grobian: And in the interest of reaching consensus, double.
20:44 <@grobian> Chainsaw: I'm willing to go there, but not if you can remove an eclass in 30 days
20:45 <@jmbsvicetto> as I said, I'm fine with both 30 or 60 days
20:45 <@Chainsaw> grobian: Yes, I see your point that eclass removal/API change should both require the same delay.
20:45 <@Betelgeuse> it should be noted that with eclass removal you can't install the thing
20:45 <@jmbsvicetto> ulm: should we start counting votes?
20:45 <@Betelgeuse> with minor api changes you could install a thing but wrongly
20:45 <@ulm> jmbsvicetto: yes
20:45 <@grobian> dropping the eclass vs a function is as bad to overlays (the only ones it should hurt)
20:45 <@Chainsaw> That is the failure scenario I dread the most, Betelgeuse.
20:45 < Calchan> ulm, yes, let's start voting but state exactly what we're voting on
20:45 <@ulm> Let's first vote if we need an additional rule at all.
20:46 <@Betelgeuse> ulm: it's not really additional as I said
20:46 <@ulm> And if this is accepted, let's vote on a wording.
20:46 <@jmbsvicetto> ulm: I'd call an update to eclass policy
20:46 <@jmbsvicetto> +it
20:46 <@jmbsvicetto> and I think we should update it to cover API changes
20:46 <@Betelgeuse> ulm: So you want to first vote on if the current policy should be removed altogether?
20:46 <@ulm> Betelgeuse: Then let me suggest a wording "When removing a function or changing the API of a widely used eclass, make sure that it doesn't break any ebuilds in the tree, and post a notice to gentoo-dev at least 30 days in advance."
20:47 <@Chainsaw> ulm: That sounds good, yes.
20:47 <@grobian> jmbsvicetto: that's too vague.  Feels like we should push that back for discussion
20:47 <@grobian> the agenda topic was just whether or not you can remove functions from an eclass
20:47 < Calchan> grobian++
20:47 <@jmbsvicetto> grobian: I didn't meant it to be vague. I'm just arguing that what we're talking about fits inside the already existing eclass policy (or policies if you prefer)
20:47 <@jmbsvicetto> ulm: +1
20:48 <@Betelgeuse> ulm: +1 preferably with a patch incldued
20:48 <@grobian> jmbsvicetto: yeah, so in that case, I say, no vote, because it's a non-issue at the current state, as Betelgeuse already replied iirc
20:48 <@ulm> Betelgeuse: You volunteer to provide a patch? ;)
20:48 <@jmbsvicetto> grobian: so you would prefer we create / set a single eclass policy listing all rules about eclasses?
20:48 <@Betelgeuse> ulm: in the email to gentoo-dev :)
20:49 <@grobian> I would love to see a discussion on APIs in general on eclasses, and how to deal with them
20:49 < Calchan> ulm, s/widely// and s/30/90/ and it's a yes
20:49 <@Betelgeuse> ulm: but yes I can patch devmanual
20:49 <@grobian> if we should use versioning, strict API rules + versioning like libtool does
20:49 <@ulm> Calchan: I'm against the 90 days
20:50 <@Betelgeuse> grobian: My idea was to vote something to replace the current policy. The finer details could evolve in later meetings.
20:50 <@jmbsvicetto> grobian: if so, then I'm fine with pushing this back to the mls. If not, I think what ulm suggested, with Betelgeuse's note about adding a patch to the eclass, seems reasonable to add to the current rules
20:50 <@Betelgeuse> So does the current rule stand until we reach a decision?
20:50 <@grobian> Betelgeuse: makes no sense to me to vote for something that's not yet there
20:50 <@Betelgeuse> As such QA should start encorcing things?
20:50 <@Betelgeuse> or anyone else
20:51 <@ulm> In principle we have 4 votes in favour for the proposed wording...
20:51 < Calchan> ulm, between no rule and 30 days I'll take 30 days
20:51 <@Chainsaw> ulm: Which does sound like a majority.
20:51 <@jmbsvicetto> ulm: if you didn't, count me as +1 on the proposed wording
20:51 <@grobian> Can we then please open the discussion on the MLs too?
20:51 <@jmbsvicetto> grobian: seems a good idea to me
20:51 <@Chainsaw> Calchan: Exactly. We should propose a change of the duration later. An easy yes/no vote that should have no problems making it onto the agenda.
20:51 <@grobian> ulm: and, can you remove "widely-used"?
20:52 <@jmbsvicetto> grobian: we can even present it as a reform of eclass policy (policies)
20:52 <@grobian> you should NEVER break any ebuild in gx86
20:52 <@grobian> regardless how insignificant
20:52 < Calchan> ulm, I'm with grobian, "widely" opens a nasty door
20:52 <@grobian> "common sense"
20:52 <@ulm> generally used?
20:52 <@grobian> ulm: all eclasses, period
20:52 <@Betelgeuse> ulm: all eclasses
20:52 < Calchan> ulm, we only have one class of eclasses
20:52 <@Chainsaw> ulm: Don't give people a chance to argue terminology. Eclass. You can't discuss your way out of that.
20:52 <@ulm> ok, s/widely //
20:53 <@grobian> a used eclass, erm, so an unused one you can drop all functions from?
20:53 <@Chainsaw> ulm: No further objections your honour.
20:53 <@ulm> grobian: that's covered bu "removing eclasses" I guess
20:53 <@ulm> *by
20:53 <@grobian> When removing a function or changing the API of an eclass, make sure that it doesn't break any ebuilds in the tree, and post a notice to gentoo-dev at least 30 days in advance.
20:54 < Calchan> ulm, grobian is right, just say eclass, make it simple
20:54 <@jmbsvicetto> grobian: + with a patch of the proposed change
20:54 <@ulm> grobian: yep
20:54 <@grobian> jmbsvicetto: patch: 30 lines of -
20:55 <@grobian> jmbsvicetto: but if you prefer, I could live with that
20:55 <@ulm> Who will start the discussion about 30/90 days in -dev?
20:55 <@jmbsvicetto> grobian: until you can check the patch you won't know whether it's 30 lines of -, 100 of +, or a complete rewrite of the eclass ;)
20:55 <@grobian> jmbsvicetto: ok, you convinced me… sigh, python anyone?
20:55 <@jmbsvicetto> ulm: the discussion is not about 30/90 days, but about general rules for an eclass policy
20:56 <@grobian> eclass ABI policy
20:56 <@jmbsvicetto> ulm: what can be changed in an eclass without requiring using a new version, what type of API consistency is required, etc
20:56 <@grobian> what changes need review on -dev ML
20:56 <@ulm> k
20:56 < Calchan> ulm, so are we done voting, or can we start, and on what?
20:57 <@ulm> yes, I think we're done with that topic
20:57 <@ulm> next: open bugs
20:57 <@grobian> I think I can try to start a discussion on the eclass API thing
20:57 <@grobian> if noone else wants
20:57 <@ulm> grobian: good
20:57 <@jmbsvicetto> grobian: be my guest
20:57 <@ulm> bug 331987
20:57 < willikins> ulm: https://bugs.gentoo.org/331987 "Merge -council and -project mailing lists"; Gentoo Infrastructure, Mailing Lists; UNCO; scarabeus:infra-bugs
20:58 <@ulm> any progress there?
20:59 <@jmbsvicetto> I think infra is waiting for our reply to antarus numbers
20:59 <@ulm> "The council decided to move these subscribers to gentoo-project and send them a message informing them how to remove themselves from the new gentoo-project mailing list." says the October summary
20:59 <@grobian> 54 people, move, send them a notification they're now subscribed to -project
20:59 <@jmbsvicetto> given the prior discussion, I think we all agree to have infra move the 54 people subscribed to council, but not project to the latter ml
21:00 <@ulm> So, who will take care of it?
21:01 <@grobian> can we just cut and paste that sentence in the bug?
21:01 <@jmbsvicetto> ulm: I'll bug infra and leave a comment in that bug later
21:01 <@ulm> jmbsvicetto: o.k.
21:01 <@ulm> bug 341959
21:01 < willikins> ulm: https://bugs.gentoo.org/341959 "council changed the waiting period in "eclass removal policy""; Doc Other, Devmanual; IN_P; tove:qa
21:02 <@ulm> "hwoarang agreed to talk to tove about that and sort it out."
21:02 <@ulm> hwoarang: any progress?
21:02 <@hwoarang> sorry i didn't. i will try again
21:02 <@ulm> k
21:02 <@jmbsvicetto> ulm: bug 383467
21:02 < willikins> https://bugs.gentoo.org/383467 "Council webpage lacks results for 2010 and 2011 elections"; Website www.gentoo.org, Projects; CONF; hwoarang:jmbsvicetto
21:03 <@ulm> jmbsvicetto: right, that's the last one
21:03 < Calchan> some would say that reflects reality :op
21:03 <@ulm> jmbsvicetto: "jmbsvicetto will take care of that on behalf of the elections team."
21:03 <@jmbsvicetto> I wasn't able to get to this before, but I've already copied the old elections results to the elections space and I'll be fixing the links there from the council page later today
21:04 <@ulm> good
21:04 <@jmbsvicetto> so I should be able to close this bug today or up till the end of the week
21:04 <@ulm> any bug that I've missed?
21:05 <@ulm> if not, open floor
21:05 <@grobian> ok, open floor
21:06 <@grobian> anyone?
21:07 <@ulm> seems not to be the case
21:07 <@ulm> let's close the meeting then
21:07 <@grobian> cool, then my connection survived
21:07 <@ulm> thanks everybody
21:08 <@grobian> ok, thank you mister chairman
21:08 <@ulm> I haven't done an online summary, but I hope I can do it tomorrow
21:09 <@ulm> grobian: you'll be next chair, btw
21:09 <@jmbsvicetto> ulm: thanks for chairing
21:09 <@jmbsvicetto> ulm: do you need me to send you the log or want me to commmit it?
21:09  * Chainsaw bows to all and disappears
21:09 <@ulm> jmbsvicetto: would be nice if you'd just commit it
21:10 <@jmbsvicetto> ulm: will do
21:10 <@ulm> thanks