15:00:24 #startmeeting 15:00:24 Meeting started Wed Sep 3 15:00:24 2014 UTC. The chair is jwb. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:24 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:24 #meetingname workstation 15:00:24 The meeting name has been set to 'workstation' 15:00:25 #meetingtopic Workstation WG meeting 15:00:25 #topic init 15:00:25 #chair jwb mclasen cwickert juhp ryanlerch cschalle kalev ltinkl otaylor 15:00:25 Current chairs: cschalle cwickert juhp jwb kalev ltinkl mclasen otaylor ryanlerch 15:00:32 hi all 15:00:35 who's around? 15:00:40 * langdon lurking 15:00:42 * mclasen is here 15:00:42 hi 15:00:45 * cwickert is here 15:00:50 #chair juhp_ 15:00:50 Current chairs: cschalle cwickert juhp juhp_ jwb kalev ltinkl mclasen otaylor ryanlerch 15:00:52 cschalle is moving, so probably not going to be around today 15:00:55 hello hello 15:01:01 mclasen, what a slacker :) 15:01:16 * cwickert crosses his fingers that we won't have any netsplits this time 15:01:20 cwickert, same 15:01:36 i think ryanlerch is still on PTO, so he won't be joining us eitehr 15:02:09 let's give otaylor and ltinkl just one more minute 15:02:51 owen was in another call earlier, let me poke him 15:02:55 ok 15:03:06 o/ 15:03:26 stickster, ? 15:03:43 hi otaylor 15:03:43 jwb: that was just waving hello. I came in a couple minutes late. 15:03:44 sorry to be late 15:04:01 * satellit listening 15:04:01 stickster, ah. i thought you were raising your hand for a question. clearly school has started in the US 15:04:04 ha 15:04:08 ok, let's get rolling 15:04:15 #topic net-install for Alpha 15:04:25 i think we're up to TC5 now for composes 15:04:25 so, I've been fixing this up 15:04:38 kalev, excellent. want to give an overview? 15:04:48 right, so when I started it was in a very sad state 15:05:14 it would basically just boot an anaconda that only allowed selecting minimal install 15:05:34 anaconda on netinstall is a very different beast than what's on the live media 15:05:52 why is that ? 15:05:58 and is entirely based on comps groups, whereas on the live media we can do excludes / additions in the kickstart file 15:06:11 so the first step to get there was to move all package selection to comps 15:06:25 and I've done that now and we have a workstation-product comps group 15:06:35 oh, yes. you mentioned that 15:06:44 kalev, nice 15:06:45 so if anyone needs to add / remove packages, do it there and don't add stuff to kickstarts 15:06:52 #info kalev has been fixing this up. created workstation-product comps group 15:07:09 and I've adopted the kickstarts to this and it seems to roughly work 15:07:15 at least as much as our side is concerned 15:07:30 * juhp_ did a net install with TC5 and it seemed to go reasonably well 15:07:33 very nice. i plan on trying the next compose in a VM for this as well 15:07:36 there's still an anaconda / release engineering issue that anaconda doesn't know how to select the right path where to fetch Workstation comps 15:08:05 we should probably document this (need to do all in comps) somewhere - at least with a comment in the .ks file 15:08:06 so in practice it doesn't really work, but I believe releng and anaconda folks are looking into it 15:08:21 I'll make sure we have a comment there 15:08:30 #info anaconda/rel-eng looking into comps path issue 15:08:49 kalev: Are there other things that the kickstart does these days that the netinstall will miss? 15:09:03 #action kalev to add comment in Workstation ks files to add packages to comps group instead 15:09:11 there are some minor differences 15:09:33 one is that the live media includes anaconda and all its dependencies and it's also installed to end user systems; netinstall doesn't pull in anaconda 15:09:46 kinda nice 15:09:48 and netinstall has like 3-4 extra packages that are related to language support, like hunspell-en or something 15:09:57 I don't remember the exact names, was very minor 15:10:06 kalev: I guess we want hunspell-en on live too 15:10:33 kalev: I've always considered that (anaconda left behind) a flaw of live installs 15:10:34 kalev: do we know where hunspell is coming from? is it a dependency or a default in some other comps group` 15:10:35 ? 15:11:08 mclasen: yes, would be very nice to have a two-layer setup on the live media where anaconda lives in a separate overlay or something so it's not pulled in to the final install 15:11:18 mclasen: it definitely is, same for the spins and their guidelines, but too late to change it for F21 I guess 15:11:50 cwickert: not sure where it comes from, I think the depsolvers that are used on live media and the one in anaconda are different 15:12:07 I see, thanks kalev, great work 15:12:10 I think live still uses yum 15:12:11 kalev, do you need help with anything in particular for netinstall at this point? 15:12:12 it might be that anaconda has its own, DNF based depsolver and livemedia-creator uses yum, or something 15:12:16 mclasen, +1 15:12:21 and anaconda based pulls in some extra packages 15:12:39 jwb: no, everything is done from our side as much as I'm concerned 15:12:50 kalev: well done 15:12:55 well done indeed! 15:13:12 I should be possible to post-remove anaconda, no? 15:13:14 kalev, awesome. big thank you for just going and getting this done 15:13:18 erm it should * 15:13:27 juhp_: not in a clean way 15:13:29 kalev++ 15:13:32 hm 15:14:21 #info follow up with ways to remove anaconda from the set of packages installed in the final live image 15:14:31 anything more to discuss on netinstall, or move on ? 15:14:37 ok, we can all think about this a bit. probably not an F21 item 15:14:41 mclasen, yeah, let's move on 15:14:49 nothing more from me 15:14:52 #topic Workstation Marketing/Release notes 15:15:06 so cshalle sent some marketing notes to the WG this week 15:15:23 i thought they were well written, and Pete Travis from the docs/marketing team seemed to agree 15:15:30 did everyone get a chance to read them over? 15:15:39 jwb, +1 15:15:43 * kalev hasn't read it yet. 15:16:37 when you get a chance, please read them over and reply if you have concerns/additions 15:16:41 * cwickert likes them 15:16:49 did cschalle forward it to the list ? 15:16:54 not yet 15:16:56 I don't think so 15:17:03 ah, ok 15:17:04 only the WG members so far 15:17:08 * mclasen goes to dig in another folder 15:17:26 so related to this, we have a couple things concerning release notes 15:17:36 they are, in no particular order: 15:17:37 * randomuser perks up 15:17:41 1) hardware requirements 15:17:59 2) included in default install or not (and where) 15:18:16 3) do we want each product to have it's own release announcement? 15:18:44 let's start with hardware requirements/suggestions 15:19:03 Can someone summarize what the current proposal is for hardware requirements? 15:19:10 f21 seems a bit more memory hungry than f20? 15:19:17 so 1GB is good enough for extremely minimal usage in a VM, but not installation as reported on the list, so I suggest 1.5GB minimal? 15:19:17 * stickster mentions jzb so he can lurk if desired, since we're talking about release announcement/notes 15:19:42 elad661, ok 15:19:53 elad661, i was thinking the same. 1.5GB minimum, 2GB+ recommended 15:20:08 is 1.5GB enough for installation? did anyone test that? 15:20:17 I tested with 2GB in a vm and it runs smooth 15:20:25 i can test that with the next compose 15:20:34 I'm *tempted* to say a recommend of 4GB - for a "workstation" that seems modest 15:20:35 me too 15:20:46 (testing) 15:20:54 it works *well* with 2GB 15:20:56 ...but almost exclusionary 15:21:46 2GB does seem to work well generally. we can always phrase it as "recommend 2GB or more" 15:22:01 randomuser: I sort of agree, but am a little worried about sounding like we're exceptionally heavy - while the 4GB really just reflects modern websites and browsers and usage patterns 15:22:01 jwb++ 15:22:15 jwb++ 15:22:25 i think that should mostly cover the DRAM recommendations. do we want to suggest particular CPU families? 15:22:26 most people will have 4GB anyway, if you recommend 4GB they'll think you're really bloated 15:22:32 elad661, right 15:22:39 otaylor, it's more to the point about the overall *type* of system that comes with 4GB out of the box 15:22:48 on CPU... i'd rather not even suggest a 32-bit CPU 15:22:56 elad661: works well for the bare desktop, or while using apps 15:22:56 +1 that too 15:23:10 yeah, we don't want people using Workstation on 32bit if they can avoid that 15:23:16 sure 4GB is fine for bare metal but not for guests so much 15:23:29 the generic 'more is better' copy will still be there, fwiw 15:23:35 yeah but we're not telling users they can virtualize on 4GB 15:23:52 elad661, erm... we're not telling them they can't either 15:23:55 so they'll assume they can 15:24:17 okay so let's add something: if you want to use Boxes, it is recommended to have more than 4GB of RAM 15:24:20 or something like this 15:24:35 elad661: I don't think that's necessary 15:24:38 to clarify virtualization is heavy, but the system is quite light compared to competitors 15:24:51 on the virt environment: i'm in favor of jwb's point about recommending a spice/qxl situation (presumably boxes does that?) and not addressing unsupported platforms 15:24:54 elad661: Even fedora+fedora is OK with 4GB if you need to 15:25:07 otaylor, i agree. i've done that many times 15:25:08 ksmd ftw! 15:25:09 (I just meant that I don't want to use 4GB guests normally:) 15:25:29 multiple VMs on a 4GB host gets painful, but a single VM running at a time is generally ok 15:25:40 elad661: The recomemndations should talk about using Fedora on bare metal or a guest- using fedora as a host for VM's is "app usage" 15:26:22 anyway +1 for "2GB+ recommended" 15:26:27 thats normally understood, right: "with more required depending on the used applications" 15:26:27 I did run it in a 2 GB netbook and the result was fine, so I suggest "2 GB or more". 15:26:36 right 15:26:47 * mclasen is using 2GB for his test vms regularly, so +1 15:26:50 jwb: So we want to say "64-bit CPU recommended" ? 15:26:59 otaylor, i'd like to say that 15:27:17 jwb: That seems fine to me - if we think 4GB or more is optimial, people shoudln't need to reinstall if they add more memory 15:27:45 do we need to make a recommendation for the architecture? I mean, 32bis is dying anyways 15:27:52 jwb: just recommending 64-bit also is good in keeping things simple 15:28:08 cwickert, not fast enough 15:28:18 jwb: true that :) 15:28:40 ok, so 2GB for DRAM, 64-bit CPU recommended 15:28:40 * mclasen is +1 on '64-bit recommended' too 15:28:47 anyone have objections to either of those? 15:28:49 so probably the main WS download page might only link directly to 64bit images 15:29:04 juhp_: yes, and with a smaller link for 32bit 15:29:05 juhp_, yes, we can definitely look at that 15:29:26 okay 15:29:35 I mean as long as we generate 32bit image there's no point hiding it 15:29:45 sure 15:29:54 I would want to have a single download on the main page 15:30:00 #agreed 2GB+ DRAM, 64-bit CPU recommended for hardware requirements 15:30:02 like Get Workstation Here 15:30:03 kalev: sure 15:30:15 if we want to drop 32bit completely I'm all for it, but not for this cycle 15:30:32 There *is* still a residual stigma about 64bit incompatibility, an explicit recommends seems reasonable to me 15:30:49 incompatibility? 15:30:52 plus, i think websites will be making 64bit the default offer 15:31:05 randomuser: 64 has been default for a while 15:31:08 kalev, right that sounds attractive - and maybe an "Other downloads" page 15:31:13 elad661, +1 15:31:21 jwb, I don't pretend to support these misconceptions or understand them, just observe people's behavior 15:31:29 what about VMs? Is the recco 64bit? or 32bit? 15:31:46 langdon: 64bit still, I think 15:31:49 langdon, "don't care but 64bit" 15:32:12 people that want to use 32-bit VMs to avoid python memory usage overhead aren't going to be installing Workstation in their VM 15:32:14 * randomuser would also like guidance on the storage footprint recommendations, but it could go back to the list if meeting time is short 15:32:18 langdon, for WS I would say the same applies 15:32:31 ok.. no particular opinion but i feel like most of the inter-tubes still seems to suggest 32bit for VMs in general.. 15:32:33 langdon: I think it's 64-bit for simplicity - though it would be interesting to know if there is a signfiicant difference in free memory booting a 32-bit or 64-bit image in a 2GB vm 15:32:57 we need to test this 15:32:59 langdon, yes. except most of the intertube VMs aren't running desktop systems in them. 15:33:33 jwb: point 15:33:36 otaylor, +1 15:33:51 #info recommendations for VMs are also 64-bit 15:33:52 and +1 to otaylor 15:34:02 otaylor, care to follow up on that? 15:34:18 jwb: I can, yes 15:34:21 otaylor, great, thanks 15:34:42 #action otaylor to compare memory differences between 32 and 64-bit VMs 15:35:01 randomuser, can we take the storage recs to the list? save us some time here 15:35:09 yes, that would be great 15:35:12 ok 15:35:20 * elad661 can do some testing wrt storage 15:35:26 elad661, that would be great 15:35:41 #action elad661 to do some testing for storage recommendations 15:35:51 ok, subitem 2) whither to install release notes 15:36:05 i honestly don't know where the list discussion landed on this 15:36:20 There was some suggestion to have them as PDFs on the ISO itself 15:36:25 instead of the installed system 15:36:38 that would make them available offline and also for people before they actually boot the system 15:36:58 randomuser, how difficult would that be? 15:37:33 jwb, from my perspective, it isn't difficult to provide a PDF; publican can output lots of formats 15:37:45 we'd have to ask releng about putting it on the media, though 15:37:48 yup 15:38:01 or we could simply package it 15:38:07 in fedora-release-workstation 15:38:07 how difficult is it to squeeze content 'under the crust' of the .iso like that ? 15:38:20 dgilmore could tell us if he's around. 15:38:20 mclasen, if it's in a package, very 15:38:21 And if we do that,are tehy going to be available from the booted live image? 15:38:31 I still maintain that providing rhe release notes prominently in the product will be a valuable thing for Workstation users that want information about their newly installed product 15:38:40 I don't think tehy need to be available from the booted image 15:39:07 I don't think it's any more valuable than just having it as a delivered bookmark/open tab in the browser 15:39:13 randomuser: In general, wouldn't we prefer that people got to them live on the internet rather than a canned copy? 15:39:14 I guess they are handy if offline... 15:39:50 i have no overwhelming opinion, but if i was installing something new i'm much more likely to read about it _before_ i actually install it 15:39:53 do we have any data on whether people regularly consult the release notes ? 15:40:06 otaylor, I just prefer that people get them, period. The delivery mechanism isn't *that* important... 15:40:11 * mclasen personally admits to 'never ever' 15:40:30 randomuser: they will be visible prominently on the website 15:40:39 but I can say [colloquially] that people regularly have issues or questions that would have been avoided if they had read the release notes 15:40:47 lol 15:40:54 which suggests to me that people should be reading the release notes 15:40:58 yeah, well, having them visible won't make people read them 15:41:04 "you can lead a horse to water..." 15:41:10 removing an exposure vector won't help there 15:41:12 it also suggests to me that going through a lot of effort to put them on the media or in packaging is not well spent. 15:41:18 randomuser: it also won't harm 15:41:42 if your system is installed and working you probably don't need the release notes, I think 15:41:47 so does someone have a concrete suggestion/proposal? perhaps something like "include a bookmark to the release notes in firefox"? 15:41:51 randomuser: however, making it plainer where to find them at the time people download the product, including an easy PDF download link, would be more useful. 15:41:55 stickster, well, that too, but tagging the git repo and bumping the spec isn't exactly a trying endeavor. 15:41:57 jwb: we already do include the bookmark 15:42:03 afaik 15:42:13 elad661, shows how often i read them... /me runs away sheepishly 15:42:45 stickster, point. I'll update my copy of stg.fp.o and talk to websites about it 15:43:14 ok, so we're at "don't install them in the Workstation images" now, correct? 15:43:28 that sounds like the right proposal 15:43:42 randomuser: I'm implementing the re-design of the start page now, there will be a link to "get help" there, very big one, clicking on it would lead to a page which would show a link to the release notes 15:43:46 I don't care if they are installed or not, as long as they are easy to find 15:44:00 I think that would give them decent exposure 15:44:00 ok, so let's go with that 15:44:17 #agreed don't install the release notes in the workstation images. work with docs and websites to make them easy to find 15:44:47 subitem 3) do we think we need separate release announcements for each product? 15:45:06 e.g. one big F21 release announce for each milestone, or 3 separate ones 15:45:16 jwb: just fyi we'd need to talk with QA to remove "installing the release notes" from the final criteria 15:45:20 elad661: that would at least be firing up a browser, two clicks and looking. I think this is already a big setback compared to now. 15:45:34 elad661, ok, i'll amend to include that 15:45:42 cwickert: most users won't know "release notes" means "help" 15:45:43 jwb: I prefer separate release announcements 15:46:05 jwb: A unified release announcement is inevitably going to spend a whole lot of time on features that aren't relevant to workstation users 15:46:17 right 15:46:19 otaylor, i'm leaning that way as well 15:46:20 you can probably have an 'umbrella' announcement 15:46:27 yes 15:46:31 that just refers to the individual product announcements 15:46:33 Have a big announcement linking to more detailed ones 15:46:37 yes 15:46:37 alpha/beta announcements are typically terse; if there's a split announcement, it should probably happen only for GA 15:46:43 elad661: but most users wouldn't know that "help" also means "release notes". In fact, "Help" assumes you are having a problem, while release notes are general information. 15:46:55 randomuser, that sounds okay 15:47:09 cwickert: when is the last time you used the release notes launcher? 15:47:29 Do you *actually* use it? 15:47:37 elad661: yes, after I installed F20 15:47:40 randomuser: I agree 15:47:45 randomuser: I think mostly that when we have a release annoncement that goes into marketing about why you care about this, it has to be product specific 15:47:45 in fact I just used it yesterday 15:47:54 cwickert: you're very special then, most people I talk with don't ever click on it 15:47:56 hopefully *someone* used it to test the new desktop file :P 15:48:07 randomuser: I did, and filed a bug too 15:48:11 * stickster notes, everyone here is special, so nothing we personally do is really a good test case for "most users" 15:48:33 true 15:48:41 yep 15:49:02 Okay so back to the topic on hand, separate release announcements for GA, shared for alpha and beta? 15:49:12 so: umbrella announcement that points to separate product announcements for final release. shared for alpha/beta 15:49:18 jzb: Does that agree with current plans for release announcements? ^ 15:49:19 elad661, I think it is a good approach 15:49:25 jwb++ 15:49:31 jwb, +1 15:49:34 * mclasen tries to find the release notes bookmark in firefox, not easy 15:49:38 * stickster not sure if Marketing is thinking about this, looking for our recommendation, or what 15:49:57 stickster, jreznik asked we discuss it because it was raised on the marketing list 15:49:58 I think Marketing would welcome recommendations in any context 15:49:58 mclasen: +1, not intuitive 15:50:04 jwb: ah, right on 15:50:12 cwickert: I'll include a direct link in the start page for the first month after GA 15:50:22 * jreznik is reading 15:50:27 elad661: fair enough, but "most people" is very vague. my point is: when you proposed the removal of the launcher, you said the release notes would be linked from start.fpo. and get.fpo. Now you say they will be linked from another help document, that is yet to be done. 15:50:27 cwickert: like we did on the main page of fedoraproject.org before 15:50:32 is that good? 15:50:38 Like, it's orange and it sticks out 15:50:40 if we want to make a bookmark findable, it probably has to be in the 'new tab' grid at least 15:50:45 we call it "the newsbar" in websites 15:50:48 mclasen++ 15:51:14 stickster: yes, it's discussed on marketing list, so when I saw agenda for this meeting, it was best place to ask 15:51:22 * randomuser would be happy do discuss a replacement presentation of the RNs on the list 15:51:25 elad661: I've heard at least 3 different statements from you now. please come up with a propsal, or even better with a draft. try to get a buy in from docs before we make a decision. ok? 15:51:28 we have 10min left. i'd like to get to the image viewer topic if we can 15:51:29 mclasen, good idea 15:52:09 * mclasen drops his random musings about bookmarks and sits straight 15:52:17 does anyone have any issues with the release announcement proposal? 15:52:19 which was: 15:52:20 cwickert: Okay, let me rephrase: direct link from get.fpo, plus extra link from help page, and a very very prominent link from start.fpo for the first month in addition to the link from the help page 15:52:21 so: umbrella announcement that points to separate product announcements for final release. shared for alpha/beta 15:52:28 jwb: umbrella announcement with separate announcement for final and share alpha/beta makes sense for me (especially during alpha/beta time there's not much time to prepare real big announcement) 15:52:38 jwb: +1 15:52:43 +1 15:52:43 jwb: +1 15:52:51 +1 15:53:08 sure, +1 15:53:10 #agreed umbrella announcement that points to separate product announcements for final release. shared for alpha/beta 15:53:21 ok, let's move on to the image viewer topic 15:53:25 #topic Default image viewer 15:53:26 elad661: lets discuss it on the list when you come up with a concrete proposal. 15:53:33 * jreznik is going to reply with it to the marketing list, thanks jwb 15:53:37 jreznik, np 15:53:38 * cwickert is in favor of eog 15:53:40 so image viewer 15:54:00 cwickert, i agree. we stick with eog for now, and we can look at switching to gthumb or gphotos for f22 15:54:01 what is developed more actively? 15:54:10 jwb: sounds good 15:54:16 If eog is installed by default and it's not the default handler, it's doing nothing 15:54:27 good point, elad661 15:54:28 elad661, right 15:54:36 right now shotwell is the default handler 15:54:41 and both are installed by default 15:54:58 i think, after reading the thread 3 times, most people seemed to agree shotwell wasn't well suited to this 15:55:15 okay, but there was also the concern of "changing the defaults too often" 15:55:18 one thing I would like to avoid is changing image viewers every cycle 15:55:24 what elad661 said :) 15:55:51 but I also like to think of F21 as starting fresh with a whole lot of polish 15:56:16 what was the other image viewer we would switch to in f22 ? 15:56:20 eog was the default a while ago. i view it more as a return to simplicity while we wait for gthumb/gphotos 15:56:41 mclasen: Photos, probably? 15:56:49 yeah, Photos 15:56:55 when Allan says it's ready :) 15:56:56 I certainly don't think switching to gthumb makes sense if F22 isn't clear for what we want as a manager app. 15:56:56 sorry, that's what i meant by gphotos 15:57:06 otaylor, right 15:57:39 I'm afraid that photos will probably end up with a similar poor fit than shotwell 15:57:49 There doesn't seem to be a ton of difference between eog and shotwell actually if you run them on a jpg - shotwell seems to start in some sort of viewer mode 15:58:18 But the existence of that viewer mode in itself is a bit confusing - your running shotwell, but where are all the management features? 15:58:57 right. and i think mizmo had mentioned something about eog being easier to "flip through" with a number of photos 15:59:42 owen: 'not a lot of difference' is that an argument in favor of switching (since most people won't notice) or against (because not a lot of win) ? 16:00:03 if we switch, it's one less package installed by default and a smaller image 16:00:14 (mabye) 16:00:20 mclasen: I think it was a weak argument against - it's not like we throw a manager app when you double click on a photo 16:00:45 otaylor, so you're arguing for leaving things as they are and revisiting for f22? 16:00:47 jwb: Is te proposal to not install shotwell, or just switch the default view action? 16:01:03 otaylor, i guess that's up for discussion too. let's settle on the default first :) 16:01:07 jwb: I think I'm actually in favor of switching the default to eog but leaving shotwell installed, and revisiting for f22 16:01:15 otaylor++ 16:01:26 I think it makes sense. 16:01:46 i agree as well 16:01:51 sounds okay 16:01:53 anyone care to differ? 16:01:59 I care to concur 16:02:04 heh 16:02:08 sure, sounds like a plan 16:02:30 cwickert, want to weigh in? 16:02:36 we're at 2min over, but we're soooo close 16:02:44 yeah just this one last thing 16:03:04 jwb: sorry, I already did. 16:03:14 you did? 16:03:17 oh, he did 16:03:22 basically he agreed at the start 16:03:24 I said I am in favor of eog 16:03:25 so yay 16:03:40 okay, all done then :) 16:03:41 and I think we can remove shotwell, but I don't really care 16:03:48 #agreed switch default image viewer to eog but leave shotwell installed. revisit for F22 16:03:54 WHEW 16:03:56 cwickert: I think it's just bikeshedding at this point (removing or not) 16:03:59 :) 16:04:12 ok, that was actually productive. amazing what functioning irc can provide 16:04:27 thanks for coming everyone. we'll end for today and be back on the regular schedule next week 16:04:37 thanks jwb 16:04:37 do we have a meeting next week? 16:04:37 yep, that was a good meeting, thanks 16:04:41 kalev, we do 16:04:45 ok 16:04:51 kalev, today was a one-off to cover stuff we should have gotten to last week 16:05:03 * kalev goes to drop release notes from the image. 16:05:14 thanks again everyone 16:05:16 #endmeeting