15:01:54 <adamw> #startmeeting Fedora QA meeting
15:01:54 <zodbot> Meeting started Mon Jul  1 15:01:54 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:00 <adamw> #meetingname fedora-qa
15:02:00 <zodbot> The meeting name has been set to 'fedora-qa'
15:02:03 <adamw> #topic Roll call
15:02:10 * pschindl is here
15:02:14 * tflink is here
15:02:34 <dan408\> hi
15:02:59 * mkrizek is here
15:03:06 * Cerlyn is here
15:03:08 <adamw> set phasers to FUN
15:03:40 * jreznik is there, would like to leave a bit earlier, so go on, go on!
15:03:54 * brunowolff is here
15:04:32 <adamw> #topic Fedora 19 retrospective and wrap-up
15:04:56 <adamw> so, we got F19 tested and out the door with only a one week slip - big congratulations to everyone!
15:05:15 <adamw> in case anyone missed the ML message:
15:05:22 <jreznik> yep, thanks everyone!
15:05:27 <adamw> #info I put the retrospective page up recently at https://fedoraproject.org/wiki/Fedora_19_QA_Retrospective
15:05:36 <adamw> you can add feedback on the *QA* process to that page
15:05:51 <Southern_Gentlem> adamw,  my question is how the sudo switch is missing from the gnome install
15:06:05 <adamw> Southern_Gentlem: the GNOME team does not want it to be optional.
15:06:13 <adamw> it's by design for that tool.
15:06:36 <adamw> that doesn't quite tie in with anaconda views it, but then i don't think we're quite at the point where GNOME gets to define the UI of *the entire distribution* :)
15:06:54 <Southern_Gentlem> so first boot you have to give admin priviledges to the first user
15:06:56 <adamw> if GNOME was designing the installer, it wouldn't have a switch either: the first user account would always be an admin.
15:07:03 <Southern_Gentlem> something wrong with that
15:07:08 <adamw> if you install GNOME and don't create a user in anaconda, yes.
15:07:09 * dan408\ sips coffee
15:07:49 <adamw> so let's see, as well as general f19 stuff, some leading questions...
15:08:09 <adamw> anyone particularly worried about any specific bugs that slipped through the net and have ideas to do anything about them?
15:08:36 <tflink> other than the mac bug?
15:09:13 <dan408\> no
15:09:15 <tflink> nvm, already on the list
15:09:15 <adamw> including that, if we have anything productive to contribute
15:09:28 <adamw> though personally i'm not hugely concerned about that one
15:09:55 <dan408\> it's good ol' fedora
15:10:12 <tflink> yeah, I don't have anything to contribute that hasn't already been said
15:10:42 <adamw> can anyone think of any issues we need to document that aren't documented already?
15:11:01 <tflink> I'm minorly concerned about what criteria the cloud folks want to add, but that can wait until they're proposed
15:11:54 <robatino> i'm already seeing bugs 946964/955779 on one of my newly installed F19 boxes. i think it may be a common issue
15:11:57 <dan408\> nothing really, same usual questions popping up in #fedora
15:12:12 <dan408\> grub questions, video drivers, getting up and running
15:12:20 <dan408\> these are pretty much documented
15:12:47 <adamw> cool
15:12:54 <adamw> so no big new stuff
15:13:14 <dan408\> no.
15:13:35 <dan408\> i really dont see anything major at the moment
15:13:46 <adamw> robatino: if you can clarify that one it could certainly be a commonbugs candidate, but I haven't had issues using gdm in KVM virt machines
15:13:56 <adamw> thanks dan
15:14:10 <dan408\> np
15:14:18 <robatino> i'm seeing it on bare metal now (on a machine with blacklisted 82865 video)
15:14:32 <robatino> i'll be investigating more
15:15:19 <adamw> for the record, i've done most of the obvious commonbugs entries, the ones remaining are mostly ones that aren't entirely clear, but i'll take another pass through the list today
15:15:30 <adamw> anything more for f19 or shall we move on to the next one? :)
15:15:35 <jreznik> thanks adamw for commonbugs
15:15:54 <dan408\> the next one ?
15:15:58 * dan408\ gets scared
15:16:02 <adamw> f20!
15:16:06 <dan408\> NO
15:16:09 <dan408\> :(
15:16:45 <dan408\> 2 weeks vacation for all
15:16:48 <adamw> #info Fedora 20 is cancelled, dan408's orders
15:16:59 <dan408\> not cancelled
15:17:00 <adamw> the official QA dictionary does not know the meaning of the word 'vacation'
15:17:10 <brunowolff> I added a note about getting a TC for the minor spins.
15:18:18 <dan408\> alright
15:18:46 <adamw> brunowolff: that's really up to releng
15:18:50 <adamw> we don't order them what to build
15:18:55 <adamw> we just ask for a tC
15:18:56 <jreznik> adamw: vacation? is it somehow related to vaca in spanish? :D
15:19:10 <adamw> #topic Fedora 20 planning
15:19:19 <brunowolff> It affected QA of those spins.
15:19:22 <adamw> so F19 is SO last week
15:19:28 <adamw> brunowolff: well, true.
15:19:28 * nirik would like to clearly propose dgilmore's spins critera for the f20 cycle.
15:19:40 <adamw> nirik: can you expand on what you mean by that?
15:20:29 <nirik> for tc/rc's we compose all approved spins, but spins must get 2 testers to ack that they passed basic tests. Those that do, are released for that milestone. Those that don't aren't.
15:20:37 <jreznik> for f20 schedule reference - https://fedoraproject.org/wiki/Releases/20/Schedule (see, no earlier than)
15:20:45 <nirik> if something doesn't get any acks for a cycle, it's dropped.
15:21:13 <dan408\> can these acks be done via email?
15:21:15 * nirik was going to write up something for devel/test/spins
15:21:35 <adamw> dan408\: good question
15:21:38 <nirik> whatever folks would prefer, sure.
15:21:40 <jreznik> nirik: well, we planned it in milano with cwickert too (similar, even for the big spins) - so I'm +1 for that
15:21:44 <nirik> but a wiki might be easier to track
15:21:53 <dan408\> +1 to a wiki on that
15:21:54 <adamw> we have matrices for desktop spins, we don't print a matrix for every other spin
15:21:55 <jreznik> nirik: or real ticket...
15:22:08 <nirik> yeah, could get confusing tho... with all the spins...
15:22:10 <jreznik> or matrix...
15:22:16 <adamw> a page that just had 'does it boot?' for every spin would be easy to write, i guess.
15:22:21 * nirik doesn't care how we track it really.
15:22:32 <adamw> does anyone see a major problem with the policy in general?
15:22:40 <adamw> from a QA perspective? doesn't seem like a problem for us, to me
15:22:43 <nirik> I was thinking: boots, can login, network works? (or any other basic things)
15:22:51 <dan408\> as long as we aren't dropping spins left and right due to lack of acks, im +1
15:23:15 <nirik> well, I suspect we will, but we will see.
15:23:26 <adamw> i suspect the *two* tester requirement may be too many
15:23:33 <adamw> we don't get two testers for KDE sometimes, enver mind anything else
15:23:34 <nirik> should it be 1/
15:23:35 <nirik> ?
15:23:39 <adamw> 1 seems more realistic
15:23:42 <cwickert> hold on
15:23:59 <cwickert> It depends on what you want to test
15:24:02 <adamw> and for a really basic functionality check, i don't see the need for double testing
15:24:11 <nirik> anyhow, I am not saying we approve anything. I am just saying I intend to start a clear dialog on this for f20. ;)
15:24:19 <adamw> cwickert: "<nirik> I was thinking: boots, can login, network works? (or any other basic things)"
15:24:28 <adamw> nirik: sure, understood
15:24:40 <dgilmore> adamw: my thought was the spin maintainer and one other
15:24:41 <cwickert> most spins are based on other spins, so they should have pretty good coverage already
15:24:53 <adamw> #info nirik and dgilmore will be proposing a new policy for deciding which spins to ship for F20
15:25:03 <cwickert> like the jam-kde spin inherits testing from KDE
15:25:11 <adamw> cwickert: the problem is that just adding packages can bust stuff sometimes, we can't assume a pass for the KDE spin means a pass for all KDE-derived spins
15:25:12 <jreznik> dgilmore: spin maintainer + one other makes sense for me
15:25:15 <nirik> except when it doesn't compose or has other issues.
15:25:23 <adamw> jreznik: i think sometimes, 'spin maintainer' may be all we can get.
15:25:34 <cwickert> all we then need to test is: 1) it composes, 2) it boots, 3) one can login and 4) all applications run as expected
15:25:44 <dgilmore> adamw: i know in the past they have not tested
15:25:50 <adamw> 'all applications run as expected' is a large bear trap
15:25:50 <cwickert> and this should IHNO be done by two people
15:25:54 <cwickert> owner and one more
15:25:58 <adamw> it takes about three hours to run that test for KDE
15:26:00 <dan408\> +1 cwickert
15:26:02 <adamw> and it's rarely a 100% pass
15:26:03 <nirik> even spin owner is better than what we have now.
15:26:06 <cwickert> s/IHNO/IHMO
15:26:16 <dan408\> it takes 3 hours to run that test for kde?
15:26:19 <adamw> yup
15:26:26 <dan408\> is kde really that slow?
15:26:28 <nirik> yeah, all applications is a bit crazy...
15:26:31 <adamw> just launching every damn app in the menus and testing it can do _something_
15:26:37 <dan408\> or are you talking about KDE + derivative spins?
15:26:39 <cwickert> adamw: I don't expect it to pass 100, I just expect it to be tested
15:26:40 <adamw> dan408\: no, it just has a lot of apps
15:26:44 <jreznik> dan408\: manually, yes - there are a lot of apps, you have to try to click over, load document
15:26:51 <adamw> dan408\: Desktop has rather fewer, still takes 1-2hrs though
15:26:55 <Cerlyn> testing all apps on something like the security spin would be difficult
15:26:57 <cwickert> adamw: why would it take 3 hours to test kde?
15:27:06 <dan408\> jreznik: that's what we have you for
15:27:06 <jreznik> definitely time to talk to vhumba about this one
15:27:12 <nirik> I'd be fine with that as an optional.
15:27:13 <cwickert> adamw: you mean according to the criteria I just outlined?
15:27:28 <dan408\> well KDE is a "release blocking" desktop
15:27:30 <adamw> cwickert: "all applications run as expected"
15:27:32 <adamw> anyhow
15:27:38 <adamw> we don't need to get bogged down in the details
15:27:41 <dan408\> but for a basic spin you dont need to "launch every app"
15:27:53 <adamw> yeah, that's kinda what I was saying, i don't think that test is even required
15:27:59 <adamw> maybe check the key apps for the spin, sure
15:28:03 <dan408\> yes.
15:28:10 <dgilmore> so long as people can get in, get online and open a browser is a good start
15:28:17 <dan408\> i.e. can you open a "konsole" or a "terminal"
15:28:21 <dgilmore> that the apps work as expected is a plus
15:28:23 * nirik is with dgilmore. We should walk before we run. ;)
15:28:42 <dan408\> okay
15:28:54 <dan408\> i think we are all talking about the same thing here
15:29:00 <adamw> yeah, i think dan's right
15:29:15 <adamw> no-one seems to think the idea is a screaming failure, so let's just wait for the formal proposal and we can bikeshed the details then
15:29:23 <adamw> everyone get your preferred tin of paint ready
15:29:30 <cwickert> adamw: so, how many applications are there in the menu? say 50, starting one takes 10 seconds. that makes it less than 10 minutes. you just fire them up, and see if they start, you don't test each and every menu option
15:30:13 <brunowolff> There are other details regarding arch and whether the image is optical, dd'd to usb or lcti'd to usb that should be considered.
15:30:17 <adamw> cwickert: if you literally just want to see if they run, it might take a bit less. if you want to test at least that you can do some basic operation without it crashing, much longer.
15:30:23 * nirik notes f19 xfce fails on several apps in that test right now. ;)
15:30:36 * cwickert knows
15:30:37 <dan408\> heh
15:30:48 <cwickert> LXDE has two fails
15:31:00 * adamw waves the 'next topic' hammer threateningly
15:31:31 <dan408\> maybe there should be a recompose of the live spins
15:31:43 <dan408\> but i think someone is waving a hammer so i should run
15:31:50 <Southern_Gentlem> a reduction in live spins
15:32:13 <Southern_Gentlem> desktops and provide ks for rest
15:33:04 <adamw> Southern_Gentlem: i don't think there's anything to be gained by arguing about that in a QA meeting.
15:33:07 <adamw> alright
15:33:18 <adamw> so other than this proposal, what do we need to do for F20?
15:33:27 <dan408\> uh
15:33:46 <nirik> nothing, lets ship it! :)
15:33:48 <adamw> i have a few things lined up: I need to continue revising the final criteria (which got stalled during final validation), and i'd like to go through the whole validation test case set
15:33:49 <dan408\> how are we pracitcally dealing with "features"
15:33:49 * nirik runs
15:33:57 <dan408\> nirik: you have to compose it first
15:34:04 <nirik> there are no more features. There are now changes. ;)
15:34:17 <adamw> #info adamw will continue with Final criteria rewrite and look at updating the validation test case set
15:34:25 <dan408\> nirik: right
15:34:39 <adamw> dan408\: is the question 'how do things change for QA with the new Changes process'?
15:34:44 <adamw> if so, excellent question
15:34:48 <dan408\> yes
15:34:52 <dan408\> sure
15:35:07 <adamw> nirik: can you help us with that?
15:35:22 * dan408\ is trying to help with a "change" for 20
15:35:38 <nirik> I could try. ;) I don't think things change too much aside from that the 'standalone' ones vs system wide might help with what you need to test?
15:36:50 <dan408\> i guess for me it was more of a better understanding, and now i guess it's more for adamw to write criteron for standalone vs systemwide changes?
15:37:13 <adamw> i don't know if there's some kind of obvious criterion
15:37:19 <adamw> and i'm not the only one who can write criteria :)
15:37:19 <dan408\> there is
15:37:23 <adamw> if you think we need one, draft one up
15:37:41 <dan408\> so i guess there should be a decision of whether certain systemwide changes should be "release blocking" or not
15:37:44 <adamw> the distinction between 'standalone' and 'systemwide' should give us some clues of what to test
15:38:01 <dan408\> fesco is no longer voting on these things anymore
15:38:04 <adamw> well, what would it mean for a Change to be 'release blocking'?
15:38:04 <dan408\> they are just proposed
15:38:25 <dan408\> adamw: Well, do we plan any more anconda "improvements" for 20?
15:38:49 <dan408\> Gnome 3.10 would be a systemwide change wouldn't it?
15:39:03 * jreznik would be glad so see qa involved in change process - especially what we miss now is the final ON_QA validation step - especially for the bigger system wide ones...
15:39:37 <dan408\> Well what fesco used to vote on, who votes on it now? QA?
15:39:55 <adamw> as in voting on whether features are 'approved'?
15:39:58 <jreznik> dan408\: FESCo still votes on both
15:40:01 * nirik gets back. what?
15:40:08 <dan408\> thank god
15:40:16 <adamw> nirik: who's right, jreznik or dan?
15:40:22 <jreznik> just for systemwide - FESCo wants change by change, for selfcontained - in batch
15:40:29 <nirik> right.
15:40:47 <nirik> actually I thought we were just approving selfcontained unless someone asked for a vote.
15:40:50 <nirik> but either way.
15:41:08 <jreznik> if somebody is not ok with selfcontained being selfcontained - it could be raised to fesco to vote on as nirik says
15:41:27 * dan408\ thinks all systemwide changes should be approved by fesco
15:41:32 <nirik> all of them go to devel list for comment.
15:41:33 <adamw> i think that's clearly the case
15:41:41 <nirik> all systemwide ones must be passed by fesco
15:41:47 <adamw> okay
15:41:53 <dan408\> then self contained can just go to devel list
15:41:58 <adamw> so we don't need to try and take that function over or anything, dan. but thanks for raising it
15:42:16 <dan408\> right because there's obviously confusion there
15:42:36 <adamw> dan408\: i think everyone's clear that systemwide Changes are reviewed, though. which is the important thing
15:42:48 <dan408\> so i guess once that's done
15:42:51 <adamw> we should certainly read the threads on devel@ and point out concerns we have with Changes from a QA perspective, btw
15:42:54 <dan408\> we can get to testing these things
15:42:59 <adamw> i've been doing that, but it'd be great if others can too
15:43:14 <dan408\> well jreznik needs to send out the list..
15:43:41 <dan408\> i kind of made a copy for 20 out of panic
15:43:43 <jreznik> adamw: yes, that's one important thing from qa perspective
15:44:03 <adamw> dan408\: each systemwide Change should show up as its own thread on devel@
15:44:06 <jreznik> adamw: and that other part is validation of at least of systemwide changes
15:44:18 <dan408\> http://fedoraproject.org/wiki/Releases/20/FeatureList
15:44:22 <jreznik> aka is it really implemented?
15:44:22 <dan408\> there is nothing up there
15:44:29 <adamw> well, that gets back to the question I asked Dan above
15:44:32 <jreznik> dan408\: it's not used anymore
15:44:42 <adamw> what does 'validation' of a feature mean exactly?
15:44:47 <nirik> we should remove/fix that page
15:44:52 <dan408\> jreznik: which is bad imo
15:44:57 <adamw> that the feature works 100%? that it works at all? that it doesn't cause breakage in anything else? what?
15:44:58 <dan408\> how do we track this now
15:45:29 <nirik> there will be another page without the word "Feature" in it?
15:45:30 <adamw> good question dan
15:45:33 <jreznik> dan408\: it's going to be replaced by https://fedoraproject.org/wiki/Releases/20/ChangeSet - being, sorry, only two accepted changes and I have to change my script to generate right list
15:45:46 <jreznik> nirik: yes
15:45:46 <adamw> nirik: i'd expect the 'FeatureList' location to re-direct to the new list for at least a few releases
15:45:53 <dan408\> why are we confusing the hell out of people?
15:45:56 <adamw> i don't know about anyone else, but XX/FeatureList is in *my* muscle memory
15:45:58 <jreznik> adamw: of course I can do it
15:45:59 <nirik> and possibly not in wiki... up to jreznik
15:46:17 <dan408\> adamw: +1
15:46:40 <dan408\> that is why i basically copied the wiki page at the time
15:46:47 <dan408\> http://fedoraproject.org/wiki/Releases/19/FeatureList
15:46:50 <dan408\> this is beautiful
15:46:56 <jreznik> adamw: the idea was to extend the list with more info - not only a list but a place with details - see the ChangeSet template... there should be docs, marketing and I'm more than happy to track QA status there too
15:46:58 <adamw> redirect to Releases/20/ChangeSet would be fine.
15:47:20 <jreznik> adamw: ok, I redirect from old policy and yeah, I'll do it for a few releases too
15:47:24 <adamw> so my take on 'validating features' has always been that, well, we validate the release
15:47:27 <adamw> features are a part of the release
15:47:28 <jreznik> for FeatuesList/ChangeSet
15:47:40 <adamw> if they break something important, our validation tests should catch that
15:47:52 <jreznik> adamw: release is validated, does it mean some changes are really implemented? no
15:47:54 <dan408\> I guess we will repropose E for f20 as a "self contained" feature
15:48:04 <adamw> but i'm not sure if that philosophy is water-tight; we might want to reconsider
15:48:06 <jreznik> dan408\: do it please and let me knwo
15:48:21 <dan408\> let's make sure that whatever is listed under the features category is moved to the changes category
15:48:46 <adamw> jreznik: so, you want us to test that the Changes all actually work? that's another bunch of work for us to do, i guess
15:48:54 <dan408\> #link http://fedoraproject.org/wiki/Features/Enlightenment
15:49:05 <jreznik> adamw: one thing is - we know release is ok, but we are never 100% sure if all changes are ok and you know, we do release announcements (and many times we realized hey, it's actually not there etc.)
15:49:13 <adamw> #info jreznik would like to see functional validation of Changes for F20
15:49:22 <adamw> volunteers welcome...
15:49:26 <jreznik> adamw: that's the question if it's doable...
15:49:36 <adamw> well, we can look at that
15:49:41 <adamw> for now let's move on as time is getting short
15:49:45 <tflink> yeah, that sounds like a lot of additional work
15:50:07 <dan408\> jreznik: I guess you just need to check http://fedoraproject.org/wiki/Category:FeatureReadyForWrangler
15:50:09 <jreznik> tflink: it is but it's something we miss now :(
15:50:10 <adamw> #action adamw to add an item for Change validation discussion to next week's agenda
15:50:20 <adamw> let's discuss it in more depth next week
15:50:42 <jreznik> dan408\: I'm in touch with owners and we're migrating it from features to changes
15:50:42 <adamw> #topic Taskbot
15:50:52 <dan408\> jreznik: okay
15:51:14 <adamw> wanted to check in on the current status of taskbot
15:51:14 <adamw> #chair tflink
15:51:14 <zodbot> Current chairs: adamw tflink
15:51:24 <adamw> what's the news, flinkonian one?
15:51:31 <tflink> not much to say, getting ramped up now that F19 is mostly over
15:52:05 <tflink> I want to get something in place before F20 starts up
15:52:20 <adamw> that'd be nice
15:52:30 <tflink> but most of AutoQA is running on F17, so that may need fixing sooner than later
15:52:36 <adamw> ah, yes
15:52:57 <adamw> #info current AutoQA setup is running on F17 which will go EOL soon: we may need to spend time moving it to something newer
15:53:12 <tflink> the fedora version doesn't really matter much for our current tests
15:53:30 <tflink> but it seems like bad form to be running on an EOL version
15:53:57 <dan408\> well time to upgrade to 19 or "rawhide" ?
15:54:17 <tflink> yeah, it's just a lot of work
15:54:28 <adamw> i'm not sure if it's worth wasting a lot of work for 'bad form'
15:54:39 <adamw> if there's no actual security issue to running an EOL'ed Fedora for the test machines...
15:54:52 <tflink> they're all behind a firewall
15:55:02 <dan408\> do they have selinux enabled? :P
15:55:03 <tflink> everything publicly accessible is running el6
15:55:20 <tflink> dan408\: not sure I see how that matters
15:55:29 <tflink> they don't even have public ips
15:55:29 <adamw> just a joke, i think
15:55:30 <dan408\> kind of a joke
15:55:37 <adamw> so, i'd consider that question before spending a bunch of time on it
15:55:51 <adamw> especially if there is a realistic road ahead to taskbot in a reasonably short timeframe and this would delay that
15:55:58 <tflink> yeah, I was hoping to avoid upgrading if we can
15:56:03 <adamw> maybe work with infra to see what they think
15:56:19 <tflink> about the upgrade?
15:56:22 <adamw> yeah
15:56:28 <tflink> that's all us
15:56:30 <adamw> if they can think of an actual practical reason we may need to do it
15:56:32 <adamw> ah okay.,
15:56:58 <tflink> but it would be worth asking if they can see an issue with the plan
15:57:40 <adamw> right, more input always valuable
15:57:45 <adamw> as for taskbot, what were you hoping to get in place?
15:57:53 <tflink> I
15:58:09 <tflink> I'd like to get something mostly equivalent to AutoQA soon
15:58:09 <nirik> reinstalling thing should be pretty easy I would think... but happy to discuss details.
15:58:45 <tflink> nirik: there are some complications in doing that which lead back to the mess that is the method we use for sysadmin
15:58:46 <adamw> well, that'd sure be nice if we can do it
15:59:07 <adamw> is there stuff that people can help out with? I see john dulaney has been trying to help with depcheck testing
15:59:10 <nirik> tflink: yeah, lets talk in admin later and hash out a plan.
15:59:30 * tflink has another meeting @ the top of the hour
15:59:44 <tflink> at the moment, not much - there are still way too many variables
15:59:50 <adamw> okay
15:59:55 * nirik nods. Later is just fine.
16:00:02 <adamw> we can move the test day topic to next week
16:00:06 <tflink> ideas for tests, or even better - code
16:00:11 <Martix_> adamw: I'm here
16:00:22 <Martix_> adamw: but I'll be here also next week ;-)
16:00:34 <adamw> #info we're hoping to have a functional taskbot in place during F20 cycle
16:00:42 <adamw> Martix_: the date on the special request wasn't super soon, was it?
16:01:03 <Martix_> adamw: what special request?
16:01:09 <adamw> it isn't, okay.
16:01:11 <adamw> let's do that next week
16:01:15 <Martix_> ok :-)
16:01:15 <adamw> #topic open floor
16:01:32 <tflink> wait, I got the time wrong on the next meeting. oh well not much to say right now, anyways
16:01:45 <adamw> anyone have anything important we didn't cover?
16:02:16 <dan408\> i think we're good
16:02:29 <jreznik> no blocker meeting follow up today? :)
16:02:38 <adamw> f20 blockers, sure :)
16:02:44 * adamw found one yesterday
16:02:54 <dan408\> ack
16:03:41 <brunowolff> Semi related to QA is that spin-kickstarts has been changed to be easier to build.
16:04:12 <adamw> awesome, thanks bruno
16:04:24 <dan408\> yup saw your email on that
16:04:28 <adamw> #info spin-kickstarts package build process has been improved, which may make it less of a pain to do s-k updates
16:06:09 <adamw> anything else, folks?
16:06:22 * adamw attaches Quantum Fuse to Cat
16:06:41 <tflink> that brings up bad images
16:07:00 <adamw> =)
16:07:32 <adamw> okay, thanks for coming out everyone
16:07:41 <adamw> #endmeeting