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