15:00:33 <adamw> #startmeeting Fedora QA meeting
15:00:33 <zodbot> Meeting started Mon Sep 30 15:00:33 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:33 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:37 <adamw> #meetingname fedora-qa
15:00:37 <zodbot> The meeting name has been set to 'fedora-qa'
15:00:42 <adamw> #topic Roll call
15:00:43 * pschindl is here
15:00:47 * tflink is present
15:00:51 <adamw> #chair tflink
15:00:51 <zodbot> Current chairs: adamw tflink
15:00:53 * Cerlyn_ is here
15:00:54 * mkrizek here
15:01:01 * brunowolff is here
15:01:04 * roshi is here
15:01:06 * kparal here
15:01:32 * cmurf is conscious
15:01:39 <cmurf> barely
15:01:54 <adamw> ahoyhoy folks
15:01:59 <adamw> welcome to the uk
15:02:03 <tflink> wait, we're supposed to be conscious for the meeting?
15:02:23 * spoore is lurking
15:02:26 <roshi> tflink: it's generally good form
15:02:38 <roshi> but not *totally* required I don't think
15:02:39 <spstarr_work> hello
15:02:46 <adamw> it depends how good your bot is
15:02:55 <adamw> mine has been running things here for the last six months
15:03:24 * adamw arrived in the UK yesterday, still getting settled
15:03:27 <kparal> adamw: except for the unexpected breakdown during August/September
15:03:48 <cmurf> adamw: Canada kicked you out?
15:03:54 <adamw> just on vacation
15:04:00 <adamw> well, visiting folks
15:04:07 <cmurf> oh ok I thought there was a story. nevermind.
15:04:08 <spstarr_work> :)
15:04:17 <adamw> nothing to see here
15:04:22 <adamw> continue about your business, citizens
15:04:55 <adamw> alrighty, looks like that's everyone
15:05:04 <adamw> #topic Previous meeting follow-up
15:05:18 <adamw> tflink: "tflink to talk to releng about where to file bugs in the cloud .ks and whether it needs to be packaged in the distro" - anything?
15:05:44 <tflink> nope, forgot
15:06:04 <adamw> .fire tflink
15:06:04 <zodbot> adamw fires tflink
15:06:16 <adamw> #action tflink or someone competent to  talk to releng about where to file bugs in the cloud .ks and whether it needs to be packaged in the distro
15:06:57 <adamw> #info "adamw to get F20 common bugs page up and populated" - this was done: https://fedoraproject.org/wiki/Common_F20_bugs . Do add or mark with 'CommonBugs' keyword any other bugs you think ought to be listed
15:07:02 <spstarr_work> lol :D
15:07:31 <adamw> #info "adamw to send the update criteria to 'production'" - I went ahead and did this, though can't remember if I sent an email note out about it or not
15:07:37 <adamw> so that should be good for beta
15:07:47 <cmurf> email went out i saw it
15:07:49 <spstarr_work> while you banter I'll grab lunch downstairs quickly :)
15:08:03 <adamw> #info "adamw to check if any further criteria changes are needed to beta/final for arm/cloud" - had a quick think about it and couldn't come up with any, but i should check with the arm and cloud folks
15:08:07 <adamw> cmurf: a
15:08:07 <adamw> ta
15:08:15 <adamw> anyone got any notes on those items?
15:09:30 <adamw> guess not!
15:09:39 <adamw> #topic Fedora 20 Beta pre-TC1 planning
15:09:50 <adamw> so, TC1 is due tomorrow
15:09:59 <adamw> does anyone know of any crazy emergencies we should be worrying about at this point?
15:10:26 <kparal> has somebody actually asked for compose yet?
15:10:31 * kparal has to find the ticket url
15:11:02 <adamw> no, i usually just do it on the day
15:11:07 <tflink> just to ask the anaconda devs to build with that live keyboard fix
15:11:10 <adamw> no particular reason to file it ahead of time
15:11:13 <adamw> tflink: ah, good point
15:11:20 <adamw> new anaconda is always a good idea
15:11:26 <tflink> people seem to be filing it about once a day
15:11:38 <adamw> #action adamw to talk to anaconda devs and get a build done for beta tc1 with live keyboard bug fixed
15:11:39 <adamw> yeah
15:13:20 <adamw> GNOME 3.10 is done, so that's one thing out of the way
15:13:32 <tflink> have we done any raid installs yet?
15:13:42 <tflink> or many lvm-thinp installs?
15:13:48 <spstarr_work> i dont have enough HD for RAID to test :/
15:13:48 <adamw> i suppose we should focus on GNOME Software testing for beta
15:13:54 <adamw> #info GNOME Software testing will be important for beta
15:13:56 <spstarr_work> tflink: iSCSI tests?
15:14:04 <tflink> spstarr_work: I haven't done any
15:14:05 <cmurf> lvmp-thinp is working
15:14:05 <adamw> tflink: i didn't :/
15:14:16 <spstarr_work> tflink: I can look at doing some iSCSI testing
15:14:16 <cmurf> minus the extra p
15:14:17 <adamw> I don't have my RAID test box in the UK so I can't, either
15:14:22 <adamw> all i've got here is the sony laptop
15:14:50 <brunowolff> You should be able to test software raid with just one HD. It's dumb for normal use, but it should work for testing.
15:14:51 <tflink> I have the hw to do raid install tests
15:15:01 <adamw> software raid is easy to test in a VM anyway
15:15:09 <adamw> it's hw / fw raid that's fiddly
15:15:09 <tflink> true
15:15:26 <tflink> at this point, I'll probably just wait for beta tc1, though
15:15:35 <kparal> tflink: I did some raid tests during Alpha testing, both sw raid and fw raid
15:15:54 <adamw> sure, that's not really a showstopper, just something to test at tc1
15:16:33 <kparal> http://testdays.qa.fedoraproject.org/testcase_stats/QA_Testcase_Install_to_BIOS_RAID.html
15:17:18 <tflink> kparal: did we address infra's hostname concerns for that machine?
15:17:24 <cmurf> something that's coming up increasingly is hardware shipping with Intel Smart Response Technology combining SSD/HDD together. Linux cannot support this right now.
15:17:28 <kparal> tflink: no idea
15:17:50 <cmurf> anaconda doesn't have a test for this, it basically just tells the user they have no disks at all
15:18:25 <cmurf> that's in the category of RAID
15:19:03 <spstarr_work> #action spstarr to work on iSCSI install testing
15:19:11 * jskladan1 is late, but present
15:19:23 <adamw> cmurf: if we can't support it, then there's nothing much to test...
15:19:55 <adamw> cmurf: what could anaconda do instead? can we access the drives 'normally', is it just a 'note that SRT is in use rather than return nothing' case?
15:20:59 <cmurf> we can't access the drives normally, but md reports back an imsm attribute that it knows it doesn't support, so anaconda could know this is ISRT and tell the user ISRT isn't yet supported
15:21:49 <cmurf> there's a bug around here for md that i bounced back to anaconda for them to look at
15:22:56 * satellit_e listening
15:23:05 <cmurf> . 890881
15:23:10 <adamw> spstarr_work: not sure if #action works for non-chairs, i'll do it just in case
15:23:15 <cmurf> .890881
15:23:17 <adamw> #action spstarr to work on iSCSI install testing
15:23:35 <adamw> cmurf: worth keeping an eye on, then, but not world-ending
15:23:36 <cmurf> aparently the bot doesn't know what period means today
15:23:37 <cmurf> https://bugzilla.redhat.com/show_bug.cgi?id=890881
15:24:21 <tflink> isn't there a ssd cache test day scheduled? is that different than the isrt?
15:24:23 <cmurf> no it's just an fyi about raid. when a vendor like HP ships a pile of hardware with it on by default… we're going to see users wondering why the installer shows them no drives and no error messages.
15:25:12 <cmurf> tflink: it's the same general idea, as isrt, different implementation
15:26:17 <adamw> tflink: I think that's the Linux in-kernel version of SSD caching
15:26:56 <cmurf> there are two, dm-cache and bcache
15:27:01 <cmurf> i don't see anaconda options for them though
15:27:04 <adamw> of COURSE there are.
15:27:51 <cmurf> maybe ping Rolf and find out what the anaconda plans are or are not for F20?
15:27:52 <cmurf> https://fedoraproject.org/wiki/Changes/SSD_cache
15:28:00 <adamw> so, any other Beta business? it's looking more or less like 'steady as she goes'
15:28:09 <adamw> i guess i'll do a live compose test today, or just grab the latest nightly and try that
15:28:25 <spstarr_work> thanks
15:28:51 <tflink> adamw: nightlies failed last night
15:29:50 <adamw> ah, worth looking into then
15:29:58 <tflink> releng is aware of the issue, dep conflict
15:29:59 <adamw> #action adamw to look into nightly fail
15:30:01 <adamw> ok ok
15:30:08 <nirik> should be fixed tomorrow
15:30:15 <adamw> .fire nirik
15:30:15 <zodbot> adamw fires nirik
15:30:17 <adamw> TOO LATE
15:30:45 <spstarr_work> tomorrow isn't today
15:30:49 <spstarr_work> you're too slow :P
15:31:12 <adamw> darn right
15:31:16 <adamw> okay, moving on!
15:31:24 <adamw> #topic Open floor
15:31:40 <spstarr_work> continuous integration requires rapid development and testing :P
15:32:36 <tflink> as a heads up, there is noise of picking up the pace for f21
15:32:38 <cmurf> bcache support for anaconda for F21. Just saw the email.
15:33:01 <tflink> ie, having a "small" release and getting back on track for a may release
15:33:14 <spstarr_work> 'small' ?
15:33:24 * satellit_e FYI soas build Fedora-20-Nightly-x86_64-Live-soas-20130925.08-1.iso fixes https://bugzilla.redhat.com/show_bug.cgi?id=1008569
15:33:33 <tflink> yeah, what f20 was supposed to be
15:33:33 <spstarr_work> considering KDE i hope will be closer to Wayland by 21... that wont be small
15:33:39 <adamw> so, again with that plan
15:33:51 <adamw> i thought a few weeks ago people were talking about doing a *longer* cycle
15:34:05 <tflink> yeah, but the fedora.next proposal is taking time to come together
15:34:09 <adamw> wayland is probably a good thing to keep in mind in making that decision, yeah...
15:34:33 <tflink> the thought process is that there's no point in delaying a release until the various WGs have formed and figured some stuff out
15:34:34 <spstarr_work> adamw: indeed
15:34:53 <tflink> as always, there is pressure from gnome to get back to the old cadence
15:35:01 * handsome_pirate comes in just in time for open floor
15:35:20 <tflink> tickets should be filed with fesco soon
15:35:31 <adamw> #info tflink notes there's talk about a short F21 release cycle (again)
15:35:39 * handsome_pirate apologizes for getting distracted by work
15:36:16 <spstarr_work> tflink: but gnome can't dictate Fedora alone
15:36:31 <spstarr_work> if we treat KDE and MATE and others fairly
15:36:50 <tflink> it sounds like there will be a call for proposals on what we would do with a delayed release
15:37:16 <tflink> spstarr_work: I'm simply reporting what I've been hearing. not here to argue about which de does what
15:37:24 <tflink> reporting/repeating
15:37:26 <spstarr_work> tflink: ya
15:37:37 <adamw> yeah, this is more impact on QA than arguing about the idea
15:38:17 <adamw> if there is a plan for a 'small', short release, what do you folks think of proposing we go with a 'two release point' cycle?
15:38:21 <adamw> beta and final only
15:38:29 <adamw> i'd be worried about trying to cram alpha, beta and final into 4 months or less
15:38:37 <tflink> if we wanted a delayed f21, we'd have to counter the argument that there's little point in investing in infra/qa before we know where the 1 -> 3 product thing is going
15:38:38 * kalev thinks it's an excellent plan.
15:38:50 <tflink> adamw: but it's a small thing, that's no problem
15:39:21 <tflink> kalev: I think most of the people pushing for it are not as heavily affected by the short turnaround
15:40:06 <tflink> for the record, my comment about being a small thing should have had <sarcasm> tags on it :)
15:40:07 <kalev> tflink: no, I mean it's an excellent plan to drop alpha to make it easier to shorten the cycle
15:40:23 <kalev> easier on QA mostly.
15:40:23 <tflink> kalev: if you're not the one testing this stuff, sure
15:40:48 <tflink> dropping alpha on a release that would likely have more wayland stuff sounds like a bad idea to me
15:40:50 <spstarr_work> adamw: but short release means no changes to Anaconda..?
15:41:21 <adamw> well. that depends on what the definition of 'small' winds up being.
15:41:42 <adamw> if this plan has legs, we'd definitely want to push for 'small' to be serious. i.e. no mass migrations to wayland, no major anaconda changes.
15:43:56 <tflink> adamw: the question that comes to my mind is how to get that. commitments from devs?
15:44:21 <cmurf> there is X amount of work for a release whether it's small or large so i don't see much point in a small release
15:44:27 <cmurf> a lot of work for not a lot of gain
15:44:30 <dan408-> hi
15:44:33 <adamw> tflink: fesco laying down the rules at time of approving schedule?
15:44:37 <dan408-> finally made it to a meeting
15:44:43 <adamw> usually if fesco out and out says "This Shalt Be So", that's what happens
15:45:04 <adamw> cmurf: the point is to get us back on our usual schedule, specifically its tie-in with GNOME and with various holidays
15:45:29 <dan408-> is the plan to shorten f20 or f21?
15:45:43 <tflink> but if we're delaying/dropping a release, I'm not sure I see much utility in stepping up the pace for another relase
15:45:51 <tflink> dan408-: 21 or 22
15:46:07 <tflink> dan408-: sorry, wrote too quickly. shortening 21
15:46:23 <dan408-> might as well announce the shortening of 21 asap before it's too late
15:46:40 <tflink> I suspect that it'll be a topic @ the fesco meeting on wednesday
15:46:52 <dan408-> right
15:47:00 <spstarr_work> fesco should wait until wayland is integrated in the ecosystems first
15:47:02 <tflink> didn't stop us from getting caught a bit flatfooted for f20
15:47:05 <dan408-> if we limit the number of "changes" it shouldnt be a big deal
15:47:11 <tflink> s/us/me?
15:47:15 <dan408-> is gnome 3.10 complete?
15:47:21 <tflink> it was released
15:47:23 <spstarr_work> i dont want there to be egg on face if Fedora 21 is cut before KDE has wayland support (assuming its close to that timeframe)
15:47:28 <dan408-> that doesnt mean it's complete :P
15:47:34 <tflink> I assume so :)
15:47:36 <dan408-> so they are alraedy starting on 3.12 then?
15:48:09 <dan408-> spstarr_work: is KDE also on a 6 month release cycle?
15:48:49 <spstarr_work> dan408-: well, thought so, but wayland support might take longer(?)
15:48:56 <dan408-> well
15:49:10 <spstarr_work> KDE '5' is coming and i'd hate Fedora 21 to just miss it
15:49:14 <adamw> spstarr_work: well, i'd sure count a KDE migration to wayland as a 'major change'
15:49:23 <dan408-> i think talking about this here is pointless, because fesco is just going to decide what they're going to decide anyway
15:49:24 <adamw> i'd feel pretty uncomfortable trying to do that in a four month cycle. but eh
15:49:52 <dan408-> moreover, I also think basing our entire release schedule based on 1 DE's schedule is stupid. whether it's gnome or KDE, that's just my opinion
15:49:54 <tflink> it sounds like it'd be wise to keep an eye on fesco tickets
15:50:02 <adamw> dan408: the point is to determine what our concerns about the possibility are and relay those to fesco, and to think ahead about what we need to do ourselves to deal with such a schedule
15:50:05 <tflink> and plan for a break in the blocker review meeting wednesday
15:50:05 <dan408-> we'll get delayed again some day
15:50:25 <spstarr_work> adamw: they have early support in KDE 4.11 for wayland but its not even tech preview level
15:50:31 <dan408-> adamw: from a QA perspective, will we have enough time to do all the proper testing? I think yes.
15:52:37 <dan408-> okay awkward silence..
15:52:43 <adamw> tflink: point.
15:53:13 <spstarr_work> adamw: I want to think Fedora should move to a new FESCO model
15:53:14 <cmurf> so beta tc1 tomorrow?
15:53:16 <adamw> #agreed we have concerns about a short release cycle especially combined with potential upcoming features like official wayland support for KDE and/or GNOME, we will raise those with fesco
15:53:26 <adamw> spstarr_work: out of scope.
15:53:30 <spstarr_work> representation from QA (1 person) and one from infrastructure etc...
15:53:38 <spstarr_work> vs some people who are not privy to QA even
15:53:48 <adamw> #info adamw suggested the possibility of doing a beta/final only schedule for a short release cycle, tflink was worried about dropping alpha
15:53:58 <adamw> spstarr_work: still out of scope.
15:54:09 <spstarr_work> adamw: we are open floor though :)
15:54:24 <dan408-> adamw: when did the meeting go to 8am?
15:54:25 <tflink> I'm not against dropping alpha if we are actually doing a small release
15:54:35 <cmurf> floor isn't that big
15:54:38 <adamw> dan408: it hasn't changed...
15:54:44 <dan408-> hmm
15:54:49 <adamw> spstarr_work: it's open to all QA topics, not general fedora proposals :P
15:54:57 <adamw> tflink: fair enough
15:55:00 <dan408-> oh
15:55:10 <dan408-> one thing i'd like to raise that's QA related is regarding the spins
15:55:13 <adamw> dan408: did the clocks change already in your region or something?
15:55:16 <dan408-> no
15:55:30 <dan408-> im just never awake at 8AM or I'm getting ready for work
15:55:31 <adamw> what's up with the spins?
15:55:35 <spstarr_work> adamw: fair enough
15:55:42 <dan408-> ok regarding spins, a bunch of spins almost werent shipped for alpha
15:55:49 <dan408-> there is a new signoff process for spins
15:55:59 <adamw> yeah, it's been brought up before i think
15:56:06 <dan408-> so it is paramount that this gets done before the alpha/beta/final composes
15:56:26 <tflink> sure, by the sigs responsible for the spins
15:56:29 <dan408-> LXDE, Scientific, MATE, and another one almost didnt get shipped
15:56:33 <dan408-> tflink
15:56:37 <dan408-> no QA is responsible for this
15:56:43 <tflink> no, we're not
15:56:54 <dan408-> we're not responsible for testing?
15:56:57 <dan408-> alright then
15:57:05 <tflink> the sigs are
15:57:09 <tflink> for the signoff matrices
15:57:29 <dan408-> i dont think that's been properly communicated out
15:57:36 <satellit_e> +1
15:57:51 <tflink> iirc, it was part of the matrix announcement
15:58:07 <dan408-> whatever, i know now for my spin
15:58:29 <kparal> dan408: just read once again nirik's announcement. it has been posted into every major list
15:58:38 * nirik is open to ideas for more communcation.
15:59:00 <satellit_e> link should be on all testing pages https://fedoraproject.org/wiki/Releases/20/Spins
15:59:03 <dan408-> hmm
15:59:03 <nirik> if you can give me home addresses of spin owners I can send them all a flaming engraved candygram? ;)
15:59:04 <adamw> dan408: yeah, the idea is that if you want your spin shipped, you get it tested
15:59:16 <dan408-> adamw: it's not just me.
15:59:18 <adamw> spin owners could come and ask us nicely to help test, of course, but the process doesn't require us to or give us ownership of it
15:59:28 <adamw> dan408: 'you' in the general sense.
15:59:39 <adamw> i.e. it's the spin owner's responsibility.
15:59:42 <dan408-> nirik: pm
15:59:45 <dan408-> nirik: lol
15:59:51 <adamw> okay, looks like we're good
15:59:53 <spstarr_work> adamw: I'd hope the spin owners know, I'd hate to know if KDE somehow got missed in a release, but I suspect they do very well know
15:59:53 * adamw sets quantum fuse
16:00:04 <nirik> :)
16:00:08 <tflink> spstarr_work: kde and desktop are the exceptions
16:00:14 <adamw> we are responsible for KDE testing as it's a elease blocking desktop
16:00:19 <spstarr_work> tflink: oh?
16:00:20 <adamw> KDE and GNOME we're on the hook for
16:00:25 <spstarr_work> :)
16:00:25 <dan408-> i'll probably be propsoing 2 more spins for f21
16:00:26 * spstarr_work smile
16:00:44 <spstarr_work> I do KDE side easier as I use KDE
16:01:01 <dan408-> adamw: double standard ;p
16:01:30 <dan408-> anyways we luckily dodged a bullet on that one
16:02:16 <adamw> alrighty, thanks for coming folks
16:03:06 <dan408-> thanks for hosting
16:03:45 <adamw> yoooooooou're welcome
16:03:45 <adamw> #endmeeting