16:01:42 <adamw> #startmeeting F29-blocker-review
16:01:42 <zodbot> Meeting started Mon May 14 16:01:42 2018 UTC.
16:01:42 <zodbot> This meeting is logged and archived in a public location.
16:01:42 <zodbot> The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:42 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:42 <adamw> #meetingname F29-blocker-review
16:01:42 <adamw> #topic Roll Call
16:01:42 <zodbot> The meeting name has been set to 'f29-blocker-review'
16:01:49 <adamw> morning folks, who's around for the first f29 blocker review meeting?
16:02:05 * pwhalen is here
16:02:19 * satellit listening
16:02:22 <frantisekz> .hello2
16:02:23 <zodbot> frantisekz: frantisekz 'František Zatloukal' <fzatlouk@redhat.com>
16:02:29 <kparal> .hello2
16:02:30 <zodbot> kparal: kparal 'Kamil Páral' <kparal@redhat.com>
16:03:08 <sgallagh> .hello2
16:03:09 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
16:03:46 <adamw> sorry i'm a bit late, i'm all kinds of behind this morning
16:04:34 * kparal pokes lbrabec coremodule
16:05:18 <adamw> how's everyone doing
16:05:36 <kparal> monday-like
16:05:40 * Southern_Gentlem battling spring pollen
16:06:23 <sgallagh> My house is falling apart around me.
16:06:36 <adamw> that...that sounds like a blocker
16:06:51 <frantisekz> everyone sitting on the beach under coconut tree thanks to OpenQA :)
16:06:57 <adamw> proposed #agreed sgallagh's house stability is a definite f29 blocker
16:07:31 <sgallagh> Well, I neglected to mention this is because contractors are ripping out rot and repairing it.
16:07:35 <sgallagh> But thanks :)
16:08:49 <adamw> i hope you're going maximum hgtv
16:09:08 <sgallagh> adamw: I can't do that. I have a real job. Well, a job.
16:09:12 <adamw> haha
16:09:54 <sgallagh> "I walk dogs three days a week and my wife paints crotcheted hats for pernguins. Our budget is 1.6 million"
16:10:45 <sgallagh> annnnyway. I've wasted enough of our time, sorry.
16:10:52 <adamw> hahaha
16:12:24 <adamw> alllrighty, let's get rolling
16:13:04 <adamw> #chair sgallagh frantisekz
16:13:04 <zodbot> Current chairs: adamw frantisekz sgallagh
16:13:12 <adamw> #topic Introduction
16:13:12 <adamw> Why are we here?
16:13:12 <adamw> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:13:12 <adamw> #info We'll be following the process outlined at:
16:13:14 <adamw> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:13:14 <adamw> #info The bugs up for review today are available at:
16:13:17 <adamw> #link http://qa.fedoraproject.org/blockerbugs/current
16:13:18 <adamw> #info The criteria for release blocking bugs can be found at:
16:13:22 <adamw> #link https://fedoraproject.org/wiki/Basic_Release_Criteria
16:13:24 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Beta_Release_Criteria
16:13:26 <adamw> #link https://fedoraproject.org/wiki/Fedora_29_Final_Release_Criteria
16:13:28 <adamw> who wants to secretarialize?
16:14:40 <adamw> well, don't all volunteer at once
16:15:54 <frantisekz> I can take that... I'll at least have some motivation to ... automatize this :D
16:16:23 <adamw> #info frantisekz will secretarialize
16:16:45 * kparal is back, at the right time (after frantisekz volunteered)
16:17:21 <adamw> good timing, kparal
16:17:37 <adamw> we have:
16:17:38 <adamw> #info 7 Proposed Blockers
16:17:42 <adamw> #info 1 Accepted Blockers
16:17:45 <adamw> #info 1 Proposed Freeze Exceptions
16:17:47 <adamw> (all for Beta)
16:17:54 <adamw> let's get started with proposed blockers!
16:18:02 <adamw> #info starting with proposed Beta blockers
16:18:03 <adamw> #topic (1576699) unable to do vnc installation
16:18:03 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1576699
16:18:03 <adamw> #info Proposed Blocker, anaconda, NEW
16:19:22 <kparal> +1
16:19:53 <sgallagh> Yeah, barring information that this is unique to lnie's setup, +1
16:19:55 <adamw> yeah, looks pretty straightforward.
16:20:01 <frantisekz> +1
16:20:06 <adamw> (i keep thinking we have this in openqa, but apparently we don't)
16:20:06 <adamw> +1
16:20:48 <pwhalen> +1
16:21:11 <adamw> proposed #agreed 1576699 - AcceptedBlocker (Beta) - clear violation of "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
16:21:36 <frantisekz> ack
16:21:59 <sgallagh> ack
16:22:03 <kparal> ack
16:22:14 <pwhalen> ack
16:22:22 <adamw> #agreed 1576699 - AcceptedBlocker (Beta) - clear violation of "When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces"
16:22:34 <adamw> #topic (1577405) '<CompositeObject>' object has no attribute 'FirewallEnabled'
16:22:34 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1577405
16:22:34 <adamw> #info Proposed Blocker, anaconda, NEW
16:23:20 <adamw> unless someone can demonstrate some way this affects a release-blocking path, i'm gonna have to be -1
16:23:32 <adamw> nirik: is this failing the compose
16:23:33 <adamw> ?
16:24:07 * kparal agrees with adamw
16:24:18 <adamw> note the firewall-y tests in openQA are passing, this isn't some general 'everything that touches firewall during install dies' bug apparently
16:24:30 <sgallagh> Given this is failing with firewall_proxy, this may be a firewalld API bug
16:24:35 <sgallagh> hmm
16:25:17 <nirik> no, but ask patrick for more details. I didn't look at this one much.
16:25:20 <sgallagh> adamw: Does that include the server tests with enabling/disabling firewall?
16:25:30 <sgallagh> If so, I'm good with -1 blocker here
16:25:34 <adamw> sgallagh: yes.
16:25:41 <sgallagh> and it's too early to worry about FE, IMO
16:25:54 <adamw> agreed
16:26:50 <sgallagh> A puiterwijk appears!
16:26:55 <puiterwijk> So I do :)
16:27:08 <puiterwijk> Sorry, I'd not noticed the call for blocker bug meeting until just now :(
16:27:22 <sgallagh> puiterwijk: Opinion is generally -1 blocker on the firewall issue. Do you have anything to add beyond what's in the BZ?
16:27:55 <puiterwijk> sgallagh: from what I could find, this happens if you don't have a "firewall" statement in your kickstart
16:28:07 <sgallagh> Oh, interesting
16:28:15 <puiterwijk> Note: that's theory
16:28:39 <sgallagh> adamw: Is it possible that openqa doesn't hit that?
16:28:39 <puiterwijk> I have not had time to figure this out entirely, but that is the common difference between the failing vs non-failing kickstarts
16:28:51 <adamw> sgallagh: probably.
16:29:12 <puiterwijk> (basically all our kickstarts have either firweall --disabled or --enable --services=<something>, except for the container ones)
16:29:42 <sgallagh> adamw: Do we have any specific rules about firewall in the criteria?
16:29:43 <adamw> actually...no
16:29:43 <puiterwijk> I'm personally -0 blocker. I just figured I'd file it so other people can discuss it.  (I *think* it's an automatic FE... But again, wanted other people to say yay/nay)
16:30:23 <adamw> https://openqa.fedoraproject.org/tests/236941 uses a kickstart with no firewall line
16:30:29 <adamw> that passed
16:30:35 <puiterwijk> Okay, so then away goes my theory
16:30:53 <puiterwijk> Maybe non-installed status of firewalld?  (random other theory.)
16:31:01 <sgallagh> I'm -1 blocker for this.
16:31:01 <adamw> it uses http://jskladan.fedorapeople.org/kickstarts/root-user-crypted-net.ks
16:31:09 <adamw> anyway, we seem fairly -1 for now
16:31:13 <puiterwijk> Anyway, -0 for blocker yeah
16:31:17 <adamw> can always revote if understanding of the bug changes
16:31:26 <pwhalen> yea, -1 here as well
16:31:29 <sgallagh> Which also doesn't install firewalld :)
16:31:33 <puiterwijk> Yep. And I think it might be fixed soon (hopefully) :)
16:31:46 <adamw> proposed #agreed 1577405 - RejectedBlocker (Beta) - as currently understood, this does not affect any release-blocking image. If our understanding of the bug changes we will revisit this
16:31:53 <puiterwijk> sgallagh: yeah. Looking at our kickstarts, we don't do anything for firewalld.
16:31:57 <puiterwijk> adamw: ack
16:32:01 <coremodule> yikes, late but here
16:32:10 <sgallagh> ack
16:32:12 <pwhalen> ack
16:32:19 <adamw> sgallagh: firewalld is in @core, so it would.
16:32:38 <adamw> #agreed 1577405 - RejectedBlocker (Beta) - as currently understood, this does not affect any release-blocking image. If our understanding of the bug changes we will revisit this
16:32:50 <adamw> #topic (1573873) Cogl/Clutter does not support 10-bit depth colours making some Gnome applications unusable
16:32:50 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1573873
16:32:51 <adamw> #info Proposed Blocker, cogl, NEW
16:32:51 <puiterwijk> Ah, right. And we don't do @core in container ks.
16:32:57 <puiterwijk> Actually, we do --nocore
16:33:08 <puiterwijk> So yeah, I think firewalld related
16:33:14 <puiterwijk> Anyway, sorry
16:33:49 <sgallagh> Oh, so it is
16:34:10 <sgallagh> I think we established that this was a blocker in F28
16:34:16 <kparal> so, I asked Lukas to file this so that it's not swept under the rug and forgotten
16:34:21 <sgallagh> And that it was resolved *there* by dropping the failing feature
16:34:40 <kparal> it was not a failing feature, the apps were failing
16:34:42 <kparal> and still are
16:34:59 <kparal> and we disabled the feature just to be able to release
16:35:02 <sgallagh> Well, the feature was added and the apps could n
16:35:07 <sgallagh> n't deal with it
16:35:12 <sgallagh> Semantics aside...
16:35:25 <kparal> my assumption was that we will not want to do that again, perhaps wrong
16:35:44 <adamw> i think you're maybe overplaying the 'feature' angle here a *bit*
16:35:44 <kparal> but people with HDR monitors might be angry that they can't use it because of two gnome apps
16:36:06 <kparal> so that's why I told Lukas to file it so that we can discuss it
16:36:08 <adamw> so we're kinda playing bureaucracy games here
16:36:22 <adamw> but i don't think it's reasonable to block beta on '10-bit must be enabled'
16:36:54 <adamw> that's not written in the release criteria anywhere. the software has to work, is what the release criteria say. we're not really in the business of declaring that things that can be defined as 'workarounds' must go away at some given point.
16:36:58 <kparal> perhaps we should ask mesa devs whether they plan to re-enable it, and if they do, block on totem and gnome maps
16:37:19 <frantisekz> yeah, I am not sure about blocking on beta... and regarding the final, we can discuss this later
16:37:21 <adamw> personally i'm only in favour of blocking when something is actually *broken*.
16:37:35 <adamw> if we get back to the broken state, fine, we have a blocker bug. till then we do not.
16:37:37 <kparal> my intention is that we know about the problem in advance, the developers are aware of it, and it is not dealt with in the last week as in F28
16:38:04 <adamw> sure. but there's nothing to 'deal with' right now. i agree it would be good to make sure the packagers are all on the same page about this, but a blocker bug is not the most appropriate way to do that imo.
16:38:08 <kparal> the point is, if we just nack it now, and mesa devs re-enable it afterwards, we will find out again late in the cycle
16:38:14 <frantisekz> but assuming Fedora tries not to differ feature-wise much from upstream... we shouldn't keep this workaround around forever
16:38:35 <sgallagh> Proposal: shunt this over to the Prioritized Bugs process?
16:38:47 <kparal> sgallagh: it's proposed
16:39:15 <kparal> adamw: I agree we're missing a different process here
16:39:15 <sgallagh> Sorry, by "shunt" I mean "stop talking about it here unless it becomes an issue again"
16:41:23 <adamw> +1 sgallagh
16:41:26 <kparal> so my suggestion would be to ask mesa devs and add gnome devs in the discussion if needed. sure, it doesn't need to be a blocker bug, it can be an email thread or a pagure ticket. this is just something we can track easily
16:41:56 <adamw> i just like to keep the blocker process focused. frankly, personally it's annoying if there's an "accepted blocker" on the list i can do nothing about.
16:42:15 <kparal> ok
16:42:22 <adamw> we're supposed to work through the list of accepted blockers getting them fixed, for this...what do we do? there's nothing to fix.
16:42:52 <kparal> there's a discussion to be started, so that we figure out whether there's something that needs to be fixed
16:43:12 <kparal> I don't think that's that unusual for blocker bugs
16:44:06 <adamw> so, not to pick on kparal, but does anyone besides kparal think this ought to be a blocker?
16:44:13 <adamw> just want to make a decision and move on here :)
16:44:16 <kparal> I'm not saying that
16:45:14 <adamw> well, i just mean, if no-one else wants to argue +1, we kinda have a decision
16:45:24 <kparal> I figured that if mesa devs say that they will re-enable rhb10 support, then this is a blocker, yes, and if they don't (in the near future), we can drop this
16:45:38 <kparal> the goal was just to prevent late surprises
16:45:43 <adamw> i understand that.
16:46:00 <adamw> i still don't think it's necessary.
16:46:03 <kparal> alright
16:46:13 <adamw> we're all cc'ed on the bug now. we're going to notice what happens whether it's an accepted blocker or not.
16:46:16 <kparal> I'm not insisting, just explaining
16:46:27 <adamw> right. i'm just trying to get a vote done and move on.
16:46:56 <kparal> mesa devs are not CCed on that bug
16:47:12 <adamw> then we should fix that :P
16:47:18 <kparal> 👍
16:47:23 <kparal> if they read bugzilla
16:47:39 <frantisekz> we should add PrioritzedBugs to the blockerbugs app, so we won't need to have this as a Blocker to make it more visible, ..., anyway, -1 Beta Blocker from me
16:47:51 <kparal> frantisekz: good idea, patches welcome :)
16:48:13 <frantisekz> yep... added to my todo list :)
16:49:15 <adamw> proposed #agreed 1573873 - RejectedBlocker (Beta) - as things stand, nothing is broken for F29 Beta. There is no blocker bug here. If the 10-bit support is reintroduced in Mesa without affected applications being fixed, we will revisit this.
16:49:31 <frantisekz> ack
16:49:36 <sgallagh> ack
16:49:40 <kparal> ack, mostly
16:50:23 <coremodule> ack
16:50:28 <adamw> #agreed 1573873 - RejectedBlocker (Beta) - as things stand, nothing is broken for F29 Beta. There is no blocker bug here. If the 10-bit support is reintroduced in Mesa without affected applications being fixed, we will revisit this.
16:52:01 <adamw> #topic (1575650) initial-setup fails - ImportError: cannot import name 'USER'
16:52:01 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1575650
16:52:01 <adamw> #info Proposed Blocker, initial-setup, MODIFIED
16:52:35 <frantisekz> +1
16:52:36 <coremodule> +1 blocker
16:52:37 <adamw> https://openqa.fedoraproject.org/tests/236905 looks like this is fixed.
16:52:38 <pwhalen> +1
16:53:04 <kparal> +1
16:53:34 <adamw> #info openQA testing indicates this is now fixed with initial-setup-0.3.61-1 , we will close the bug
16:53:49 <adamw> #topic (1575626) libdnf does not handle module stream updates properly
16:53:49 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1575626
16:53:49 <adamw> #info Proposed Blocker, libdnf, NEW
16:54:21 <adamw> +1 with the criterion change referenced in comment #2
16:54:34 <pwhalen> +1
16:55:02 <coremodule> +1
16:55:28 <frantisekz> +1
16:56:11 <adamw> proposed #agreed 1575626 - AcceptedBlocker (Beta) - clearly violates the newly revised criterion "The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops (e.g. default graphical package manager)"
16:56:22 <frantisekz> ack
16:56:25 <coremodule> ack
16:56:45 <pwhalen> ack
16:58:06 <adamw> #agreed 1575626 - AcceptedBlocker (Beta) - clearly violates the newly revised criterion "The installed system must be able to download and install appropriate updates with the default tool for the relevant update type in all release-blocking desktops (e.g. default graphical package manager)"
16:58:16 <adamw> #topic (1574711) pki-tools cannot be installed on current Rawhide (due to tomcat version bump)
16:58:16 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1574711
16:58:16 <adamw> #info Proposed Blocker, pki-core, MODIFIED
16:58:27 <adamw> this is probably fixed by now...
16:58:38 <adamw> let's see how freeipa is failing in openqa atm (i'm sure it's too much to expect that it'd be *working*)
16:58:52 <adamw> good lord, it works
16:58:54 <adamw> it actually works
16:59:00 * adamw clutches at air, passes out
16:59:07 <frantisekz> :D ...
17:00:59 <Southern_Gentlem> adamw,  give it a week
17:01:02 <adamw> #info openQA FreeIPA tests on current Rawhide pass, indicating this is now resolved, we will close the bug
17:01:03 <adamw> Southern_Gentlem: :P
17:01:11 <coremodule> woot!
17:01:59 <adamw> #topic (1575797) Bootloader installation fails (BIOS) or installed system boot fails (UEFI) when blivet-gui partitioning used during install
17:01:59 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1575797
17:01:59 <adamw> #info Proposed Blocker, xfsprogs, NEW
17:02:18 <adamw> so, cmurf thinks this is down to XFS. i'll try and do a special run of the tests against a non-Server image today to see if they work that way.
17:02:33 <adamw> still, it seems fairly clearly a blocker.
17:02:46 * adamw brb, call of nature
17:03:34 <kparal> +1
17:03:38 <frantisekz> +1
17:04:14 <coremodule> +1
17:05:45 <pwhalen> +1
17:06:16 <sgallagh> +1 (Sorry, got a phone call, back now)
17:07:46 * adamw back
17:08:18 <adamw> proposed #agreed 1575797 - AcceptedBlocker (Beta) - accepted as a violation of the custom partitioning criteria, which clearly imply that a system installed with custom partitioning must actually boot
17:08:27 <coremodule> ack
17:08:33 <frantisekz> ack
17:08:49 <pwhalen> ack
17:09:18 <sgallagh> ack
17:09:44 <adamw> #agreed 1575797 - AcceptedBlocker (Beta) - accepted as a violation of the custom partitioning criteria, which clearly imply that a system installed with custom partitioning must actually boot
17:10:08 <adamw> OK, that's all the proposed blockers
17:10:19 <adamw> there's just one proposed FE, let's just vote on it since it's here, even though we're early
17:10:24 <adamw> #info going to the one proposed FE
17:10:26 <adamw> #topic (1577405) '<CompositeObject>' object has no attribute 'FirewallEnabled'
17:10:26 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1577405
17:10:26 <adamw> #info Proposed Freeze Exceptions, anaconda, NEW
17:10:31 <puiterwijk> adamw: well, I think that this might be an automatic blocker?
17:10:36 <puiterwijk> Per the " Bugs which entirely prevent the composition of one or more of the non-release-blocking images required to be built for a currently-pending (pre-)release"
17:10:38 <sgallagh> Did I miss the libdnf blocker?
17:10:48 <adamw> sgallagh: we already accepted it.
17:10:51 <puiterwijk> Errrr, FE*
17:10:52 <sgallagh> oh ok
17:10:58 <adamw> sgallagh: if you mean 1575626.
17:11:22 <adamw> puiterwijk: oh, you're right. i forgot we had those.
17:11:34 <sgallagh> OK, I missed it
17:11:36 <puiterwijk> I just filed it as FE to get your say on that
17:11:40 <adamw> #info this is in fact an automatic freeze exception per https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process#Automatic_freeze_exceptions
17:11:50 <adamw> puiterwijk: "These bugs can be marked as accepted by any member of one of the stakeholder groups without formal review."
17:11:54 <adamw> puiterwijk: so, next time you can do that. :P
17:12:04 <adamw> #info we will mark as Accepted.
17:12:13 <adamw> #info taking a quick look at the accepted blocker
17:12:19 <adamw> #topic (1572916) kernel after 4.17.0-0.rc2.git0.1.fc29 waits for random entropy on boot
17:12:19 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1572916
17:12:19 <adamw> #info Accepted Blocker, kernel, NEW
17:12:25 <puiterwijk> adamw: yes, that's what I thought, but as said, I wanted to ask you, given the "currently-pending (pre-)release" part read to me as "close to release"
17:12:40 <adamw> so, this is an accepted blocker...anyone know what the current state of the art on this is?
17:12:43 <adamw> puiterwijk: yeah, i tend to ignore that. :P
17:12:56 <adamw> puiterwijk: we could probably re-word it a bit.
17:13:06 <puiterwijk> adamw: we have virtio-rng inlined which alleviates things on some VMs if you have virtio passed in
17:13:22 <puiterwijk> For hardware, it's probably just "wait long enough and it will most likely boot"
17:13:46 <puiterwijk> For VMs that 1. have dracut-fips (i.e. any of the composed images), 2. no virtio, it's still blocking boot forever until you get a cat on the keyboard
17:14:22 <puiterwijk> So... I think not much changed since last review, except maybe the virtio driver inlined?
17:15:06 <adamw> right. i'm kinda wondering exactly what if anything more the kernel team is planning to do, but sounds like we don't know.
17:15:16 <pwhalen> this one makes testing difficult. vm's are fine but arm/aarch64 on serial doesnt have the cat option
17:15:47 <puiterwijk> Yeah, I think the upstream kernel conversation went dead. The downstream libgcrypt conversation also seems to have died
17:15:51 <puiterwijk> (at least from what I'vce seen)
17:15:53 <sgallagh> I really don't know why in 2018 every board doesn't just have a noise-generating chip on it.
17:16:19 <adamw> most do.
17:16:23 <puiterwijk> sgallagh: I guess "components cost money"
17:16:25 <adamw> but we still have old hardware to deal with.
17:16:45 <adamw> and VMs.
17:17:04 <puiterwijk> Also, it might very well be that a lot of boards (like e.g. X-Gene) have things in separate kernel modules, which aren't loaded yet
17:17:07 <sgallagh> VMs at least can be chained to their hypervisor's entropy
17:17:25 <puiterwijk> So it might be that we need to inline modules for more rng chips
17:19:02 <adamw> sgallagh: can be, yes. the problem is they aren't by default.
17:19:07 <adamw> (generally speaking.)
17:19:19 <adamw> puiterwijk: i also wonder what the impact of rngd.service is exactly
17:19:30 <puiterwijk> adamw: on an X-Gene system I tried this morning: significant.
17:19:36 <adamw> i mean, what works and what doesn't before rngd.service is started
17:20:16 <puiterwijk> (sidenote on VM hypervisor entropy chaining: make sure your virthost has enough entropy.... if the host has like 20 bits of entropy, guests aren't going to get much of that)
17:20:35 <adamw> anyway
17:20:41 <adamw> if we don't have much news, we don't have much news
17:21:03 <adamw> #info the dimensions of this problem are becoming more well-understood over time, but we still don't know exactly what further (if anything) the kernel team plans to do about it at this point
17:21:11 <adamw> #action adamw to ask kernel team about their plans for this
17:21:28 <adamw> #topic Open floo
17:21:30 <adamw> #topic Open floor
17:21:36 <adamw> any other business, folks?
17:22:23 <frantisekz> can't think of anything
17:24:13 * pwhalen has nothing else
17:25:19 <adamw> alrighty, thanks a lot for coming along
17:26:14 <adamw> #endmeeting