[12:00] <cjwatson> oh 'eck, I'm supposed to be the DMB chair this week
[12:00] <cjwatson> bdrung,cody-somerville,persia,geser,soren: roll call
[12:00] <cjwatson> stgraber sent his apologies
[12:01] <cjwatson> poolie: just rounding folks up
[12:01] <poolie> ok, thanks
[12:01]  * barry waves
[12:02]  * geser is "half" here (I'm at work)
[12:02]  * cjwatson tries to get the Canonical holiday calendar to load
[12:03] <cjwatson> if we can't manage quorum I'd rather know early so that poolie can go to sleep
[12:03] <poolie> thanks :)
[12:03] <cjwatson> oh, soren said he'd be on holiday
[12:04] <cjwatson> come ON, canonicaladmin
[12:04] <poolie> heh :)
[12:04] <barry> indeed, it was pretty slow last week
[12:04] <bdrung> i am there now
[12:05] <cjwatson> Cody can't usually make these times, it's too early in the S
[12:05] <cjwatson> US
[12:06] <cjwatson> so I think this only works if persia happens to be around
[12:06] <barry> cjwatson: 7am's not too early :)
[12:06] <cjwatson> it is for him :)
[12:06] <cjwatson> 9pm in .jp
[12:06] <bdrung> 7 am would be way to early for me, too
[12:07]  * barry too w/o a kid to get to school :)
[12:07] <cjwatson> ah, and Cody's on holiday today anyway
[12:07] <cjwatson> Emmet's not known to be on holiday, but if he's not around by now, I'm not sure he will be
[12:07] <cjwatson> I'll wait until :10 and then declare this meeting cancelled if we aren't quorate
[12:08] <poolie> perhaps, in the event we don't reach quorum, people who are here could give some nonbinding opinions on my applications
[12:08] <poolie> *application
[12:08] <poolie> or, guidance as to what to do
[12:09] <cjwatson> I already made some comments, and said last time:
[12:09] <cjwatson> http://irclogs.ubuntu.com/2010/12/06/%23ubuntu-meeting.txt:[20:38] <cjwatson> I have no complaints or questions but I know some people like to talk to applicants in person
[12:09] <cjwatson> bdrung,geser: would either of you like to comment on any of the applications before us?
[12:09] <cjwatson> that's https://wiki.ubuntu.com/MartinPool/DeveloperApplication, https://wiki.ubuntu.com/BarryWarsaw/MyApplication, and https://wiki.ubuntu.com/AngelAbad/MOTUApplication
[12:10] <bdrung> yes
[12:11] <geser> poolie: do you expect more person to apply for bzr (and related) upload rights? so cjwatson should make a bzr packageset
[12:11] <poolie> actually yes, that seems to make sense
[12:11] <poolie> there is a set of bzr and closely-related packages that are likely to be uploaded together
[12:12] <cjwatson> maxb comes to mind
[12:12] <cjwatson> also jelmer
[12:12] <poolie> lifeless
[12:12] <poolie> and, perhaps other people in future
[12:12]  * jelmer waves
[12:12] <cjwatson> yes
[12:13] <poolie> i guess lifeless and james are(?) already core devs, so this would be redundant
[12:13] <cjwatson> lifeless is already motu but not core-dev
[12:13] <jelmer> cjwatson: I've actually been meaning to apply for PerPackageUploader-ship but haven't finished my application yet.
[12:13] <cjwatson> james_w is a core-dev, yes
[12:13] <cjwatson> but with a reasonably plausible team of four+ that would certainly be worth creating a package set
[12:14] <cjwatson> I think that also perhaps makes poolie's application simpler; he doesn't have upload history on all the packages, but they do form part of a coherent theme
[12:14] <poolie> the main thing i want to do with this is to propose MinorReleaseException candidates for a SRU
[12:14] <geser> poolie: how much involved are you in packaging bzr? I ask because LP shows only one sponsored bzr upload for you and the debian/changelog doesn't mention you
[12:15] <poolie> at the moment, we do stable releases that are supposed to be suitable for getting in to Ubuntu updates but they seem to be stalling
[12:15] <poolie> geser: i have done packaging for it into the ppa in the past
[12:16] <poolie> most of the time either maxb or jelmer has uploaded into debian (since they are, iiuc, dd's), and it's flowed from there
[12:17] <geser> would having you PPU upload right change the workflow much (first to Debian and then sync to Ubuntu)?
[12:18] <poolie> i think the particular thing it would change is that i could execute step 4 of https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[12:18] <poolie> ie uploading to -proposed
[12:20] <geser> do the PPA packages differ much from the "official" ones? (I'm trying to judge your packaging skills)
[12:21] <geser> cjwatson: would you need to also create bzr package sets for the released Ubuntu versions (if it's possible) to allow poolie to upload to -proposed?
[12:22] <poolie> geser: no, they normally track pretty closely
[12:22] <cjwatson> I think so, and yes it's possible
[12:22] <cjwatson> albeit unpleasantly manual
[12:22] <poolie> as i said on my application, most of what i've contributed to debian and ubuntu has not been packaging-specific work
[12:23] <poolie> i don't know if that's just a kind of blindness on my part, or just that i tend to fix bugs that are in the source itself not in packaging-
[12:23] <poolie> i'm very happy with getting review/mentorship/whatever and taking things carefully
[12:23] <poolie> it just seems to me that doing that within the context of PPU may flow more easily than just asking on the bug
[12:23] <poolie> which does not seem to be working very well atm
[12:25] <bdrung> poolie: are you member of the Debian Bazaar Maintainers team?
[12:25] <poolie> no
[12:25] <poolie> i'm not a dd (i'm not sure if that's a necessary condition)
[12:26] <jelmer> poolie: it's not necessary, we'd be happy to have you as a member
[12:26] <poolie> ah ok
[12:26] <poolie> what should i do?
[12:27] <bdrung> poolie: as member you gain commit access. then you can commit your changes and once a package is ready for upload, you can ask to review and upload
[12:28] <jelmer> poolie: Create an account on Alioth (http://alioth.debian.org/) and request to join the team at https://alioth.debian.org/projects/pkg-bazaar/
[12:29] <poolie> ok, i'll do that
[12:30] <cjwatson> poolie: as a general rule what times suit you?  rather than keeping you up again I think we should try to arrange a special meeting
[12:30] <cjwatson> given the timezone difficulty
[12:32] <poolie> i'm normally awake/online-ish from about 0800 to 1900 in utc+11
[12:32] <poolie> up until about this time of day is reasonable; after midnight (+30m from now) tends to mess up the next day
[12:33] <cjwatson> so 2100-0800 UTC.  I think we'd want to aim for either end of that for maximum board-member coverage
[12:33] <bdrung> cjohnston: 0800 UTC is better than 2100 UTC?
[12:34] <geser> tab-fail :)
[12:34] <bdrung> damn, tab completion
[12:34] <poolie> 0800utc is fine with me
[12:34] <cjwatson> bdrung: possibly, I was just looking up the results from the last time I asked people
[12:34] <barry> poolie: thanks for the endorsement!
[12:34] <poolie> you're welcome
[12:35] <bdrung> cjwatson: i prefer 2100 - 2300 UTC
[12:35] <cjwatson> 0800 would lose cody-somerville and I think stgraber too
[12:35] <cjwatson> I could make it, I imagine everyone else in Europe could, it's probably OK for persia too
[12:36] <cjwatson> 2100 is presumably good for cody-somerville and stgraber, I can make it at least on some days, bdrung can, not sure about persia as it's 0600 there, soren said he could make that time range before
[12:36] <geser> 2100 - 2300 UTC suit me much better than 0800 UTC as I'm usually awake till 0000 UTC
[12:36] <cjwatson> so I agree, 2100 UTC seems better on average
[12:36] <poolie> that's even easier for me
[12:37] <cjwatson> poolie: if you could send a mail to developer-membership-board@ suggesting that time and some days in the new year, then, that would be great
[12:37] <poolie> i could do it tomorrow, or the day after, or otherwise the new year
[12:37] <cjwatson> and we can get things sorted out
[12:37] <cjwatson> I suspect holidays will intervene if we try to do it this year, unfortunately
[12:37] <poolie> ok
[12:38] <geser> cjwatson: I guess a "python" package set (for barry) would be a management nightmare, right?
[12:38] <poolie> do the board members who are present feel this is basically on track to be approved?
[12:38] <cjwatson> I suspect so
[12:39] <geser> poolie: I'm not fully decided yet, I'd prefer to see your name mentioned more often in debian/changelog (or sponsored Ubuntu uploads)
[12:39] <barry> geser: i made such a suggestion a month or so ago, but didn't get much response on it, so i gathered it wasn't a popular suggestions ;)
[12:39] <cjwatson> I can't speak for everyone else; constructed as a package set, I think it has a good chance
[12:39] <bdrung> poolie: i have a little concern if you have enough packaging experience.
[12:41] <poolie> ok, that's useful, i can work towards making sure that does show up more often
[12:42] <bdrung> poolie: your name in debian/changelog and your name as Uploader (for packages maintained in Debian) are a sign for packaging skills
[12:42] <cjwatson> I would say that the bzr packaging is not generally particularly complicated, and I'm more concerned about general level-of-caring / ability to deal with bugs; given that poolie created bzr I'm not sure there's anyone more able to meet those criteria
[12:44] <cjwatson> but I realise I probably focus less on upload history than other people here
[12:44] <poolie> i guess it's not for me in this situation to tell you how to review people
[12:44] <cjwatson> does anyone have any comments on barry's application?
[12:44] <poolie> but, when i grant access, i tend to go a lot more by "not likely to do anything rash/malicious"
[12:46] <geser> barry: I'm with micahg's comment that 26 uploads (which are mostly python related) are a very few for a "core-dev"
[12:46] <bdrung> re barry: i like to see one step before becoming core-dev. a python set would seams to be the right thing for me.
[12:46] <cjwatson> geser: *blink*
[12:47] <cjwatson> bdrung: I'm not prepared to manage a python set
[12:47] <cjwatson> very many of our present core-devs had fewer than 26 uploads before joining
[12:47] <geser> cjwatson: upload history is often a good source for judging packaging skills (getting mention in debian/changelog an other)
[12:47] <cjwatson> but it's not the only one, and it's not even necessarily the most important one
[12:48] <cjwatson> we should not laser-focus on it
[12:48] <barry> i've had a ton of ppa uploads, though i tend to keep them pruned over time
[12:48] <barry> agreed that i've been python focused, but that kind of makes sense given my background and the ongoing py27 transition :)  i do plan on diversifying once that gets more stable
[12:50] <barry> geser: but i get that more, and different, experience can't hurt my application.  thanks
[12:50] <bdrung> barry: re python: i am missing a policy document for what is recommended.
[12:51] <barry> bdrung: sorry, i don't understand
[12:52] <bdrung> barry: we want to move to dh_python2 with ubuntu-dev-tools. i was searching for documentation what needs to be put into d/control
[12:53] <barry> bdrung: ah. yes, we do need to update the debian python policy for that iirc.  i can work with debian-python to get that in.  there's a number of places that i think need updating to discuss/promote dh_python2
[12:55] <bdrung> barry: for example: should we use XS-Python-Version, XB-Python-Version, X-Python-Version? on which package do we have to depend if we want to use dh_python2?
[12:56]  * tumbleweed sticks his nose in
[12:56] <tumbleweed> bdrung: we also need some lintian checks for those at some point...
[12:56] <barry> x-python-version is recommended, and debhelper (>= 7.0.50~) is i believe the necessary dependency
[12:56] <tumbleweed> bdrung: there are also versioned dependancy requirements on python(-all)
[12:56] <tumbleweed> err, barry
[12:57] <barry> right (i was assuming that, but you know what that say about "assuming" :)
[12:57] <bdrung> it would be nice to have that in the python policy
[12:57] <barry> bdrung: totally agreed
[12:57] <barry> (it's on my todo list now)
[12:59] <geser> cjwatson: I try to not focus on upload history alone, but in barry's case the endorsements are also mostly python related (and few, so I don't have much data for judgement)
[12:59] <cjwatson> OK.  I'm going to call it a day here since we can't decide anything anyway, but I encourage people to continue these conversations on other channels
[12:59] <cjwatson> geser: that doesn't bother me for core-dev.  it's broad enough.
[13:01] <bdrung> cjwatson: for MOTUs we want to see a full range of activities like sync requests, merges, SRUs, ..., but for core-dev a specific knowledge is enough?
[13:02] <cjwatson> bdrung: it's not that specific
[13:02] <cjwatson> anyway, I give up.  it's obviously the DMB's desire that it be impossible to gain core-dev.
[13:02] <geser> cjwatson: before you leave, we should call for new DMB candidates (with christmas and vacations now)
[13:02] <cjwatson> this is exceptionally frustrating for me.
[13:03] <cjwatson> I don't think I would have bothered applying for core-dev under the current system.
[13:03] <poolie> bdrung, geser: may i ask you if, considering barry's application, you think it's very likely that he will make either malicious or careless changes to Ubuntu?
[13:03] <poolie> (and if so, what kind of situation you'd fear might happen)
[13:04] <bdrung> cjwatson: Things are never as bad as they seem (or as we say in German: Es wird nichts so heiß gegessen, wie es gekocht wird)
[13:05] <cjwatson> bdrung: this has been going on for far too long
[13:05] <cjwatson> it has been frustrating me for a long time
[13:05] <cjwatson> I've seen too many developers wasting time for months on end because our process is just too bureaucratic and scary
[13:05] <cjwatson> so they never bother applying
[13:06] <cjwatson> too much great talent going to waste
[13:06] <bdrung> cjwatson: do we have some guidelines listing the criteria for getting upload rights?
[13:06] <cjwatson> https://wiki.ubuntu.com/UbuntuDevelopers is the best we have
[13:07] <tumbleweed> poolie: I've seen barry make one or two common mistakes all (new?) debian/ubuntu developers make (i.e. not closing bugs in changelogs, poor version number choices). Not exactly serious stuff, just things that get less likely with packaging experience. I'm not *worried* about him as a core-dev, though.
[13:07] <poolie> so, if he was a core dev, he would probably make some minor or common mistakes
[13:08] <poolie> he would probably do more packaging and thereby accumulate experience faster?
[13:08] <geser> cjwatson: do you feel that we require to much "proof" of experience instead of relying more on endorsements?
[13:09] <barry> tumbleweed: agreed. one of the things i'm interested in is helping to make our tools better so those kinds of common mistakes don't happen. e.g. the syntax for bug closing is pretty strict, a typo will screw it up
[13:09] <cjwatson> I think we focus on the wrong kinds of experience
[13:09] <tumbleweed> poolie: probably, but having someone review your uploads means you are less likely to get into bad habits
[13:09] <cjwatson> sure, poolie doesn't have many uploads.  but look how much experience he has with bzr, the centre of the proposed package set in question
[13:10] <cjwatson> and for that matter barry's a stalwart of the upstream python community and has been for a long time
[13:10] <geser> cjwatson: we should focus more on the communication skills ? (e.g. asking on IRC or mailings lists if one has doubts about a change?)
[13:10] <barry> i'm also involved w/dholbach's efforts at a new packaging guide.  our current set of wiki guidelines are fairly disjoint, and oddly too much of the wrong kind of detail
[13:10] <cjwatson> in those cases I think we really just need to make sure they aren't hopelessly confused and aren't likely to screw things up too badly.  the fact that they're experienced developers should count for a lot more.
[13:10] <poolie> tumbleweed: so the concern behind that is that if someone has core-dev membership or whatever, they will never get reviews, or never seek mentorship?
[13:11] <poolie> (that may well be empirically true, for all i know; i'm just trying to make the assumptions explicit)
[13:11] <cjwatson> any experienced upstream developer is going to care about the state of the software and is likely to be mature enough to ask for help if they need t
[13:11] <cjwatson> *it
[13:11] <cjwatson> our current practice essentially says "we don't want upstream developers to get involved"
[13:11] <cjwatson> that may not be the intent but that's the effect
[13:11] <cjwatson> because we don't bother crediting that kind of work
[13:12] <poolie> geser: in my experience as a developer, if somebody has a pattern of changing things _without_ communicating or asking
[13:12] <poolie> especially when they should have known to ask
[13:12] <cjwatson> and this depresses me because those are the sorts of people we need more of in the Ubuntu community
[13:12] <geser> is packaging really that comparable with upstream development?
[13:12] <tumbleweed> poolie: it is a worry I have when I endorse people who I haven't seen ask for help. But I think enough people follow -changes and will question thigs.
[13:12] <poolie> that's a huge red flag - in fact pretty much the most important one
[13:12] <cjwatson> so we develop a self-congratulating community of people who know how to sync and merge stuff
[13:12] <cjwatson> which is all well and good but it's not the centre of everything
[13:12] <cjwatson> geser: yes
[13:12] <cjwatson> it's all code
[13:12] <cjwatson> sure, different tools, different details, it does have to be learned
[13:13] <poolie> tumbleweed: right, i think reading -changes is very healthy
[13:13] <cjwatson> but if you look at the packaging diff for your average bzr upload, it's not exactly that hard
[13:13] <cjwatson> if we perpetuate a myth that packaging is hard, people will think it's hard
[13:13] <cjwatson> it's not
[13:13] <poolie> right, months go by with nothing more than a version bump
[13:13] <cjwatson> it's no harder than your average upstream build system
[13:13] <barry> re: -changes, see my recent suggestion about diffs that i think would actually help upstreams feel more comfortable and participate more
[13:14] <maco> cjwatson: and to anyone who's looked at autotools stuff, id say easier...
[13:14] <cjwatson> well, let's not focus on autotools, I find autotools quite natural
[13:14] <geser> perhaps I'm too biases with sometimes seeing upstream fighting with packaging in #ubuntu-motu and #ubuntu-packaging (or when occassionally looking at REVU)
[13:15] <cjwatson> build systems are very much personal preference
[13:17] <bdrung> packaging is simpler than setting up autotools
[13:17] <barry> the interesting thing is that packaging, specifically d/rules is where the crazy wild west of upstream build systems meets the much more controlled environment of deb/ubu building.  deb/ubu packaging is not hard once you learn the basic guidelines, but d/rules can be quite insane
[13:18] <poolie> geser: i think there probably is some amount of fighting through failing to understand
[13:18] <bdrung> barry: having an upstream source that uses three commands to build and install the package, makes d/rules simple
[13:18] <poolie> i've seen some awful packaging into third-party debs or rpms for instance
[13:18] <barry> bdrung: very true.  upstreams don't always cooperate though ;)
[13:18] <poolie> but, what are you going to do about it? keeping upstreams out is not a very scalable answer
[13:19] <barry> otoh, as simple as 90% of upstream python packages are (or can be), i've seen lots of cruft in the d/u packaging of some python packages.
[13:20] <barry> i would *love* to be at a place where 90% of python packages have a 3 line d/rules file, but we're not there yet
[13:20] <bdrung> i recommend to simplify d/rules and create patches to achieve the same and send those patches to upstream.
[13:21] <barry> bdrung: most likely to debian
[13:21] <cjwatson> there is a trap here where we fail to distinguish personal packaging preferences from quality requirements
[13:22] <cjwatson> it's still perfectly acceptable for people to use pre-dh debhelper, for instance
[13:22] <tumbleweed> (and probably more understandable for less experienced packagers)
[13:22] <cjwatson> if they were doing the whole thing by hand without any helper at all?  these days, that most likely indicates a lack of familiarity with the tools
[13:23] <cjwatson> but we certainly aren't at the point where we can say that if you aren't using dh rules.tiny or cdbs then you're Doing It Wrong
[13:23] <barry> it's definitely true that dh has a lot of "magic", which can be good since folks don't need to worry about a lot of detail, but very bad when they do (because it's very undiscoverable)
[13:26] <cjwatson> anyway, I'm going to take my frustration to mail, I think
[13:26] <poolie> i'm going to take mine to bed :)
[13:26] <poolie> i hope you will send that mail though
[13:27] <barry> thanks for the feedback guys
[13:27] <poolie> same here
[13:27] <geser> cjwatson: looks like there is a too big divergence on what to expect from each applicant
[13:32] <angelabad> sorry, but, what about my application?
[13:33] <geser> angelabad: we aren't quorate today
[13:34] <angelabad> geser, ok, so I must wait for the next meeting?
[13:35] <bdrung> angelabad: yes
[13:35] <angelabad> ok, no problem.
[13:37] <geser> angelabad: don't worry, the other have to wait too (it's only an informal discussion)
[13:38] <angelabad> ok, thanks
[18:04] <mdeslaur> hello
[18:06] <kees> jdstrand, sbeattie: meetin' time?
[18:06] <mdeslaur> hiya kees! :P
[18:06]  * mdeslaur is excited
[18:06] <kees>      [0;1;34;94m▌[0m
[18:06] <kees> [0;1;34;94m▞▀▖[0m [0;1;34;94m▞[0m
[18:06] <kees> [0;34m▌[0m [0;34m▌▞[0m
[18:06] <kees> [0;34m▝▀[0m [0;34m▘[0m
[18:06] <jdstrand> sure
[18:07] <mdeslaur> wth is that
[18:07] <mdeslaur> ansi art?
[18:07] <kees> vt100 colors and unicode characters for a 4-line version of   o/
[18:07] <mdeslaur> ah, well that explains why I can't see it :)
[18:08] <jjohansen> hehe, /me neither
[18:09] <kees> uhm, okay, starting.
[18:10] <kees> so, I've been fighting filesystem corruption on my debmirror. I think I'm hitting bugs in either the kernel's LVM, md, or ext4 or in e2fsprogs.
[18:10] <kees> so that's slowing me down.
[18:10] <mdeslaur> kees: that narrows it down :)
[18:10]  * jjohansen hides
[18:10] <jdstrand> kees: way to narrow it down :P
[18:10] <kees> I've still got more auditing work to do.
[18:10] <kees> mdeslaur: yeah
[18:10] <jdstrand> mdeslaur: haha
[18:10] <mdeslaur> hehe
[18:11] <kees> I suspect it's the online resizing, actually.
[18:12] <kees> anyway, my week is kind of open for pre-year-end interrupts.
[18:12] <kees> I'd like to clear the audit queue
[18:12] <kees> but anyway, that's it. mdeslaur is up
[18:13] <mdeslaur> so
[18:13] <mdeslaur> today's my last day before I go on holiday
[18:14] <mdeslaur> I'll be officially back on the 3rd
[18:14] <mdeslaur> but since I suck, I'll probably be here anyway
[18:14] <mdeslaur> today, I did a cve run and will do some triage
[18:14] <mdeslaur> that's it!
[18:14] <mdeslaur> jdstrand: your turn
[18:15] <jdstrand> \o/
[18:15] <jdstrand> so, I start my end of year holiday on thursday, and will be back on the thrid
[18:15] <jdstrand> third
[18:16] <jdstrand> I will take over triage and community from mdeslaur tomorrow and wed
[18:16] <kees> I can do it thu
[18:16] <jdstrand> as for work this week, I am not planning security updates, unless something big comes up
[18:16] <jdstrand> I plan to continue on my apparmor documentation tear
[18:17] <kees> jdstrand: that's rocking, btw :)
[18:17] <jdstrand> and possibly look at the dbus stuff again
[18:17] <jdstrand> kees: thanks!
[18:17] <jdstrand> that's it from me
[18:17] <jdstrand> jjohansen: are you here this week at all?
[18:17] <jjohansen> yeah
[18:18] <jdstrand> jjohansen: cool. I'll likely poke you about some doc updates I'm working on today
[18:18] <jjohansen> sounds good
[18:22] <kees> so, for apache mod_apparmor
[18:22] <jdstrand> yes?
[18:22] <kees> should we try to write upstream tests, qrt tests, or some combo?
[18:23] <mdeslaur> we had talked about writing qrt tests
[18:23] <jdstrand> qrt seems a natural fit since we need apache around to test it
[18:23] <jjohansen> kees: both
[18:23] <kees> the apache-server-running infrastructure exists in qrt, so putting it in upstream would be irritating :)
[18:23] <mdeslaur> maybe upstream tests would be more appropriate...but we would need apache
[18:23] <kees> jjohansen: okay
[18:24] <jdstrand> though, sbeattie mentioned there is some stuff that could be added upstream as well
[18:24] <jjohansen> I think upstream should have some tests but they just don't get launched by default
[18:24] <kees> perhaps start with qrt since it's easier to get up and running and work from there?
[18:24] <jjohansen> and you need apache setup
[18:24] <jjohansen> yes
[18:24] <jdstrand> ah
[18:24] <jdstrand> that would work with qrt anyway-- we just setup apache and then run the upstream tests
[18:25] <jdstrand> kinda like we do for some of the other test suites
[18:26] <jdstrand> that should be added as a WorkItem if it isn't already
[18:26] <jdstrand> I'll add it
[18:28] <kees> okay, thanks everyone!
[18:28] <jdstrand> (added)
[18:28] <mdeslaur> thanks!
[18:28] <jdstrand> thanks kees!