16:00:24 <adamw> #startmeeting Fedora QA meeting
16:00:24 <zodbot> Meeting started Mon Dec 10 16:00:24 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:28 <adamw> #meetingname fedora-qa
16:00:28 <zodbot> The meeting name has been set to 'fedora-qa'
16:00:31 <adamw> #topic roll call
16:00:38 * jreznik is here
16:00:46 * satellit listening
16:00:48 * jsmith is lurking, and having internet issues
16:00:52 <adamw> welcome to the AGM of the grocery store bicyclists' association
16:01:06 <adamw> first on the order of business: raptor protection
16:01:11 * jskladan gets of his bike
16:01:18 * mkrizek is here
16:01:31 * j_dulaney waves
16:01:32 * jreznik has kickbike only (but the big one as he's big boy!)
16:01:50 <jskladan> adamw: i'd say - don't let raptors pass the tests, but that would probably by rasistic...
16:02:06 <j_dulaney> Raptors aint getting my bacon
16:02:06 <adamw> speciesist!
16:02:16 * j_dulaney brandishes rapier
16:02:20 <jskladan> that ^^
16:02:27 * jsmith files a blocker bug against the raptor
16:02:31 <adamw> aside from the few cyclist-munching incidents and their tendency to arrive with significantly fewer passengers, raptors make fine bus drivers
16:03:06 <adamw> man, this is gonna look super-professional in the logs
16:03:09 <adamw> tflink: ping?
16:03:13 <adamw> i know you're around, stop hiding.
16:03:29 <adamw> don't leave me alone with all these Js.
16:03:52 * pschindl is here
16:04:42 <adamw> so no viking-ice, no tflink, no kparal? fired, the lot of 'em
16:04:55 <adamw> alrighty
16:05:16 <adamw> #topic Previous meeting follow-up
16:05:50 <adamw> "adamw to brief #fedora ops and fedora-user-list regulars on fedup" - heh.
16:06:00 <tflink> sorry, trying to get the list ready for mini-blocker-review
16:06:12 <adamw> well, I've talked to a few people about it, not sure I hit everyone in the description
16:06:20 * maxamillion is here
16:06:25 <adamw> .fire tflink
16:06:25 <zodbot> adamw fires tflink
16:06:39 <j_dulaney> Heh.
16:06:42 <tflink> cool, now I can go do other stuff
16:06:45 * maxamillion runs like hell from the angry bot master
16:06:49 <j_dulaney> My greatest contribution to Fedora QA
16:07:06 <adamw> it will live on long beyond fedora QA.
16:07:15 <adamw> as long as adamw is firing stuff, a little piece of you will survive.
16:07:27 <j_dulaney> Yes!
16:07:55 <adamw> so fenrus and bob from #fedora are kind of up on fedup and grumbling about it to wwoods. not sure about user-list folks. anyone been following that list lately?
16:08:32 <tflink> not so much
16:08:34 <BobJensen> I've nothing on fedup
16:08:42 <tflink> but I keep seeing bugs about people using my siderepo
16:08:58 <adamw> BobJensen: oh sorry bob
16:09:12 <tflink> which makes me think that I need to add something to the testing docs "don't use this for production instances, see the real docs"
16:09:21 <adamw> tflink: that sounds like a plan
16:09:34 <adamw> #action tflink to clarify use of his fedup side repo
16:09:47 <BobJensen> I don't know that we have seen enough users of it honestly
16:10:09 <adamw> BobJensen: see https://fedoraproject.org/wiki/FedUp . it mostly works except when it doesn't.
16:10:21 <j_dulaney> Still?
16:10:31 <tflink> j_dulaney: still? it's brand new code
16:10:33 <adamw> BobJensen: the idea was we wanted to make sure you folks knew about fedup and could help people appropriately who try to use it, or asked 'how do i upgrade'
16:10:44 <j_dulaney> Is it still doing the "not installing kernel" issue/
16:10:49 <adamw> j_dulaney: well, I mean, like all upgraders. i'd say the same about the old ones.
16:10:51 <BobJensen> adamw: I'll add a shortcut here so if people ask I have the link anyhow
16:11:06 <tflink> j_dulaney: pretty much, but that's not a fedup issue
16:11:15 <adamw> BobJensen: there's a 'how can I upgrade' anchor in the wiki page
16:11:34 <j_dulaney> tflink:  You know what I think about that, I'll not start flamng here
16:11:40 * kparal arrives late
16:12:16 <adamw> okay, i'll brief bob a bit more in private and let's move on
16:12:31 <adamw> #info "adamw to brief #fedora ops and fedora-user-list regulars on fedup" - partly done
16:12:44 <adamw> #info "adamw to brief #fedora ops and fedora-user-list regulars on fedup" - done, and we'll come to it in a minute.
16:12:46 <adamw> grrr
16:12:47 <adamw> #undo
16:12:47 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x29840e50>
16:12:54 <Martix> what are you doing here? let's /join #fedora-test-day :-P
16:13:00 <adamw> #info "adamw to put 'enterprise storage support in newui' on next week's agenda" - done, and we'll come to it in a minute.
16:13:11 <adamw> oh god, in 'things I forgot to blog about' news...
16:13:22 <adamw> #chair tflink kparal
16:13:22 <zodbot> Current chairs: adamw kparal tflink
16:13:34 <adamw> #topic Fedora 18 Final status
16:14:01 <Martix> adamw: you still can, test week just began
16:14:21 <adamw> so to make sure everyone's on the same page - the change deadline is now tomorrow, 2012-12-11
16:14:33 <adamw> the target release date is still 2012-01-08
16:14:59 <adamw> go/no-go is, conveniently, on new year's day, when we will all be fully alert and committed to such an important decision
16:14:59 <tflink> with 28 proposed blockers and 14 accepted blockers? this should be interesting
16:15:21 <j_dulaney> Heh
16:15:31 <adamw> #info current schedule: change deadlines 2012-12-11, go/no-go 2012-01-01, release date 2012-01-08
16:15:36 <adamw> tflink: fascinating!
16:15:47 <adamw> did you clean up the proposed list for the 'obvious' bugs?
16:16:13 <jreznik> adamw: well, the go/no-go has to be definitely moved to thursday... but I'm not sure how final go/no-go looks like - it's on purpose on tuesday...
16:16:17 <tflink> I got sidetracked this morning and haven't made it through the bugs that needed testing but I have a list of stuff that needs discussion
16:16:22 <maxamillion> adamw: I have a prediction the the attendence to the go/no-go will be low ... pending the intensity of the hang overs
16:17:17 <jreznik> so it would be 2013-01-03
16:17:25 <adamw> tflink: cool.
16:17:34 <adamw> jreznik: ah, okay.
16:17:43 <maxamillion> (that was semi peanut gallery, semi serious)
16:17:44 <adamw> grr
16:17:45 <adamw> #undo
16:17:45 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x226770d0>
16:17:53 <adamw> #info current schedule: change deadlines 2012-12-11, go/no-go 2013-01-01, release date 2013-01-08
16:18:04 <adamw> #info go/no-go may move to 2013-01-03
16:18:11 <adamw> this is going to be tough enough without building a time machine. :)
16:18:29 <j_dulaney> Heh
16:18:46 <adamw> #info Beta TC1 is out and in testing
16:18:55 <jreznik> I'm really not sure why it's scheudled on tuesday... looking for veterans!
16:18:56 <adamw> no fires or explosions relating to TC1, right? it more or less works
16:19:15 <adamw> jreznik: hell if i know, i'm usually permanently wasted by this point in the schedule :P
16:19:24 * nirik has one thing to bring up at some point... lives are sometimes failing to compose... looks like a weird race condition or something.
16:20:16 <j_dulaney> nirik:  With live-image-creator?
16:20:23 <nirik> livecd-tools
16:20:38 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=885385 is the bug.
16:20:48 * jreznik is reading
16:21:36 <Viking-Ice> so we are suddenly back to 16:00 when last meeting was 17:00 utc?
16:21:40 <nirik> I tweaked with the builders yesterday and they seem fine, so not sure what changed or whats causing it. ;(
16:21:56 <adamw> #info nirik found problems with live composes of Final - https://bugzilla.redhat.com/show_bug.cgi?id=885385
16:22:02 <adamw> Viking-Ice: er...it wasn't? we've been at 1600 the whole time?
16:22:03 <j_dulaney> nirik:  It's only part of the time?
16:22:15 <Viking-Ice> adamw, ah see it now blocker bug 17:00
16:22:15 <kparal> Viking-Ice: qa meetings are at 16 utc, blocker bug meetings at 17 utc
16:22:38 <j_dulaney> adamw:  It's always 11 am Eastern time, no matter if it is daylight savings or not
16:22:42 <nirik> right. it seems unrelated to which ks is used... for example, the kde's failed this way for tc1... but later I did them over and they worked fine. I really don't get whats going wrong. ;(
16:22:47 <adamw> j_dulaney: yes, that's the idea.
16:23:01 <adamw> by 'whole time' i meant 'since the dst switch', of course.
16:23:13 <j_dulaney> nirik:  Then we can probably live with it?
16:23:26 <j_dulaney> nirik:  If at first you don't succeed, try again?
16:23:29 <adamw> #info no major showstoppers in TC1, it is viable for testing
16:23:41 <nirik> well, I think that would be pretty poor for trying to compose things...
16:24:00 <nirik> keep throwing it against the buildsystem until it works doesn't inspire confidence.
16:24:07 <j_dulaney> Aye
16:24:16 <jreznik> not good :( to just wait "to be lucky"
16:24:28 <adamw> but it works in a crisis.
16:24:54 <adamw> #info blocker list is considerable, though may be a little bit prunable
16:25:19 <adamw> tflink: how long is the list of bugs to discuss? should we do it inline or after the meeting?
16:25:44 * kparal is for a separate meeting
16:25:52 * j_dulaney notes he has a final exam in an hour
16:26:10 <j_dulaney> So, by default I will be getting off in thirty minutes
16:26:18 <tflink> I see 16 bugs on my list of 'ready for discussion'
16:26:22 <adamw> oh boy
16:26:25 <adamw> guess we're going 'after meeting'
16:26:44 <adamw> so aside from the above-noted...any major issues to resolve about 18 final status? or is everyone happy doing the blocker bug grind?
16:28:13 <adamw> or, you know, giving it all up to be a himalayan yak farmer.
16:28:18 <adamw> those are your only choices.
16:28:29 <tflink> define "giving it all up"
16:28:58 <adamw> no. you must trust to the yaks.
16:28:58 <j_dulaney> Do the criteria changes right quick
16:28:59 <jreznik> yak farmer... nice dream
16:29:09 <maxamillion> I've been really happy with F18's stability in the past week on my main workstation but I got lucky and didn't hit any anaconda bugs ... so blocker grind?
16:29:15 <adamw> j_dulaney: that's another topic
16:29:16 <j_dulaney> Can I give it all up to be a pirate?
16:29:47 <adamw> maxam: blocker grind as in, find blocker bugs, test fixes, test TCs/RCs
16:30:08 <adamw> j_dulaney: you're allowed to be a pirate on days off from yak farming.
16:30:28 <adamw> oh yeah, i did put another bullet under this heading
16:30:56 <adamw> tflink: do you know what shape fedup is planned to be in for final?
16:31:15 <adamw> i'm guessing no GUI, but are the rough edges getting knocked off? manually specifying remote location, lack of progress etc
16:31:27 <adamw> and nirik: what was the SB status of TC1? I lost track of that
16:32:00 <nirik> the signed shim is in updates-testing and was not pulled into the compose.
16:32:14 <jreznik> adamw: for GUI - FESCo seems not to require it, what's in GIT is really really very early try
16:32:45 <adamw> nirik: okay, so no real SB support in TC1. might come in next build.
16:32:59 * nirik nods.
16:33:00 <adamw> #info TC1 is not signed for SB
16:33:08 <nirik> if we pull new shim, we also need new lorax
16:34:40 <adamw> and vice versa?
16:34:58 <j_dulaney> Shouldn't, I thought
16:35:09 <j_dulaney> If I read things correctly
16:35:17 <adamw> istr nirik finding the build failed unless he pulled shim or downgraded something.
16:35:31 <tflink> that was fun, lost network for a few minutes
16:35:44 <adamw> welcome back tflink. how are the yaks?
16:35:47 <nirik> if we pull new lorax, it blows up without new shim
16:35:49 <tflink> not shaven yet
16:36:07 <adamw> right.
16:36:14 <adamw> tflink: so i was just asking what the likely status of fedup for final is
16:36:17 <maxamillion> nirik: is lorax the new pungi?
16:36:29 <adamw> as regards gui, 'smooth' operation, progress reporting
16:36:35 <adamw> maxam: they're both involved.
16:36:36 <tflink> it's getting better but I'm a bit behind on my fedup testing ATM
16:36:46 <maxamillion> adamw: rgtr
16:36:48 <maxamillion> rgr*
16:37:01 <tflink> my understanding is that there are some fixes in the pipeline that should help a few of the pain points
16:37:01 <maxamillion> the whole shim madness is something I barely understand
16:37:22 <jreznik> wwoods: are you around?
16:37:25 <adamw> maxam: i can forward you a gigantic email explanation of it i wrote if you like.
16:37:35 <adamw> #info some fixes for the rough edges of fedup impending
16:37:42 <adamw> okay, let's move on, time's a tickin
16:37:50 <adamw> #topic enterprise storage for F18/F19
16:37:53 <wwoods> I'm around! I'm also about.
16:37:53 <adamw> Viking-Ice: around?
16:37:56 <Viking-Ice> yup
16:37:59 <adamw> wwoods: too late!
16:38:02 <adamw> so this was yours...
16:38:05 <wwoods> Well then I'm outside.
16:38:09 <Viking-Ice> yup
16:38:09 <wwoods> and other prepositions.
16:38:12 <mjg59> (Crying)
16:38:18 <adamw> and, indeed, positions.
16:38:32 <j_dulaney> adamw:  I'd like the shim email as well
16:38:36 <j_dulaney> If you don't mind
16:38:50 <Viking-Ice> https://www.redhat.com/archives/anaconda-devel-list/2012-December/msg00025.html
16:38:50 <adamw> mjg59: was that email I CCed you on too outrageously inaccurate or anything? before i send it to anyone else
16:39:34 <jreznik> wwoods: (about dialog) - seems like there's another topic but if you have anything for fedup status - just fire it :)
16:40:05 <mjg59> adamw: No, it seemed reasonable
16:40:08 <adamw> Viking-Ice: what was the outcome of that? iirc, 'advanced' storage types that require interaction to enable aren't going to work in F18
16:40:11 <Viking-Ice> basically there is no UI on newUI for Enterprise/Advantage storage so enterprise admins/users will have to rely ks only
16:40:12 <adamw> mjg59: cool.
16:40:43 <adamw> #info enterprise/advanced storage types that require interaction to enable/use will not work via UI in in F18, but can be used via kickstart. UI is scheduled to re-appear in F19
16:41:21 <Viking-Ice> this ofcourse is something that needs to be mentioned in the release notes
16:41:40 <j_dulaney> +1
16:41:55 <adamw> agreed
16:41:56 <Viking-Ice> not sure if there is specific Anaconda/Installer section in the release notes
16:42:03 <adamw> do you want a #action to let the docs team know about it?
16:42:11 <adamw> or i can take it if you like
16:42:21 <Viking-Ice> no I'll handle it
16:42:25 <adamw> ok
16:42:37 <adamw> #action viking-ice to let docs team know about advanced storage for release notes
16:42:52 <adamw> anything else to cover on this or shall we move on to criteria/test cases?
16:42:57 * jreznik will recheck RN notes for it
16:45:10 <adamw> #topic Test case / criteria revision
16:45:45 <adamw> so i think my proposal on the RPM package error criterion was positively received, i'll go ahead and put that into production
16:45:53 <adamw> #action adamw to put packaging error criterion revision into production
16:46:09 <j_dulaney> +1
16:46:27 <adamw> kparal's kickstart revision proposal spawned a big discussion which was interesting but might have stranded the proposal a bit
16:46:42 <adamw> any ideas for action there? try and reset the discussion to a list of ks parameters it's plausible to 'support' for f18?
16:47:13 <kparal> I think we should vote in F18 according to our best conscience and target this new criterion to F19
16:47:26 <j_dulaney> Aye, that would be a good move
16:47:36 <kparal> it will be a long discussion yet, I think
16:48:01 <j_dulaney> Actually, I really think that criterion revisions should not take effect until the *next* release
16:48:19 <tflink> ideally, yes
16:48:29 <adamw> viking's said the same thing
16:48:43 <j_dulaney> That's been my problem with all the criterion changes in the middle of this release
16:48:45 <adamw> i don't disagree in theory, but for f18, we've kinda had to rejig things on the run or else we'd have nothing applicable
16:49:01 <jreznik> adamw: +1
16:49:26 <adamw> #action kparal to try and 'reset' kickstart criterion discussion back to the proposed set of 'supported' commands
16:49:38 <kparal> hmm
16:49:46 <Viking-Ice> can we actually do that
16:49:47 <adamw> that okay?
16:49:47 <kparal> I can try
16:50:00 <adamw> Viking-Ice: sorry, actually do what?
16:50:01 <Viking-Ice> dont we just need to say all ks command have to work and test for those
16:50:18 <tflink> I'm not sure that's practical for F18
16:50:21 <Viking-Ice> why try to split it up? ( should be easy to test as well )
16:50:23 <adamw> well the worry is that if we say that we'll find a bunch of fairly obscure bugs and then what?
16:50:34 <adamw> but i suppose we could do it that way around...test it and see how bad it is
16:50:38 <Viking-Ice> let anaconda deal with it
16:50:44 <j_dulaney> Heh
16:50:46 <Viking-Ice> it's their brokenness right
16:51:01 <kparal> adamw: well we can always waive some obscure problems, same as for graphics cards etc
16:51:12 <j_dulaney> Aye
16:51:24 <adamw> kparal: well we can do that because they're 'conditional' breakages
16:51:28 <kparal> but it becomes more tricky than with a defined set
16:51:32 <adamw> we don't have a criterion that says 'all graphics cards have to work'
16:51:34 <j_dulaney> "All KS commands should work unless they are really freaking off the wall"
16:51:41 <adamw> if we did, it'd be kinda hard to waive some graphics cards being broken :)
16:51:45 <Viking-Ice> unless they have spesific ks command that can never break or become backwards incompatible I cant see how we can
16:51:56 <adamw> so if we have a criterion that says 'all kickstart commands have to work', it seems quite hard for us to say 'well except THIS one, obviously!'
16:52:06 <Viking-Ice> so basically we should follow their list ( if exist ) or check for all existing supporting ks commands right?
16:52:31 <adamw> Viking-Ice: that was matt miller's idea, and it seems reasonable, but the problem is right now the documentation of kickstart commands is somewhat outdated and doesn't in any way define a 'core set'
16:52:37 <kparal> that goes back to my long-term complain about criteria being all-or-nothing game
16:52:39 <adamw> so for f18, it's a bit hard
16:52:50 <adamw> sigh, we seem to keep winding up on tangents here
16:53:03 <kparal> I'll try to restart the discussion
16:53:11 <adamw> the task is really just 'quantify the level of kickstart functionality we consider minimal for f18 final release', that does not seem like it should be impossible
16:53:12 <kparal> with just a core set of commands for F18
16:53:17 <kparal> and possible changes for F19
16:53:18 <adamw> and shouldn't require fundamental reimaginings of process or anything
16:53:36 <Viking-Ice> yes I just fail to see why the need to quantify it in the first place
16:54:14 <adamw> what's your alternative for dealing with whether breakages in kickstart should block f18 final?
16:54:18 <adamw> just do it case-by-case?
16:54:27 <adamw> i mean, we could do that.
16:54:40 <adamw> we could just say 'we don't want to fiddle with the criteria temporarily, so we'll just handle these one by one for now.'
16:54:52 <Viking-Ice> I would say it blocks always and questionable items dealt with on case by case bases
16:54:55 <jreznik> case by case could work for F18, especially as we do not know in what state it is...
16:55:56 <adamw> shall we go with that, then? seems straightforward
16:56:30 <tflink> it'll work, I suppose and will probably generate less discussion in the short term
16:56:49 <tflink> may lead to some interesting discussions about what is worth blocking for, though :)
16:56:50 <kparal> case by case is the best way, it just requires more time to discuss
16:56:59 <adamw> okay. well let's hope we don't get too many cases. :)
16:57:01 <adamw> #undo
16:57:01 <zodbot> Removing item from minutes: <MeetBot.items.Action object at 0x1f3f3e10>
16:57:17 <kparal> adamw: should we follow up on that discussion for F19?
16:57:33 <adamw> #agreed instead of trying to write a 'temporary criterion' we'll deal with kickstart proposed blockers on a case-by-case basis for F18 final and try to come up with a longer-term criterion for F19+
16:57:36 <adamw> I think so, yeah.
16:57:39 <kparal> ok
16:57:40 <j_dulaney> kparal That would be a good idea
16:57:43 <adamw> you want to do that now or keep it for post-release?
16:57:51 <tflink> we might want to tell the anaconda devs what we're doing, though
16:57:59 * j_dulaney needs to be off for his final final
16:57:59 <adamw> yeah, and follow up on test list
16:58:03 <kparal> adamw: I'll write a note there
16:58:13 <j_dulaney> See y'all later.
16:58:15 <adamw> #action kparal to follow up on test@ discussion to explain the plan, and let anaconda team know
16:58:16 <adamw> cya dulaney
16:58:46 <adamw> okey dokey
16:58:55 <adamw> pschindl: are you planning to work on the issues identified in your test case / criteria survey?
16:59:50 <pschindl> adamw: yes
17:00:07 <adamw> cool
17:00:13 <pschindl> I'd like to go through it this week
17:00:21 <adamw> did anyone have any worries / questions about pschindl's proposals that haven't been brought up in the thread?
17:01:39 <adamw> #info pschindl will work on his proposed final test case changes (see thread 'Final criteria/Test cases interconnection')
17:01:43 <adamw> #topic open floor
17:01:47 <adamw> anyone have anything that wasn't covered?
17:03:08 * satellit needed; a good anaconda tutorial  lots of people having problems understanding how to install
17:03:30 <adamw> the docs team are working on updating the install guide for newUI.
17:03:56 <tflink> and people having trouble with patience, aparrently
17:04:02 <satellit> +1
17:05:04 <adamw> tflink: where are we doing the blocker review this week?
17:05:19 <tflink> bugzappers, I think unless someone has a better idea
17:05:33 * kparal +1
17:05:58 <adamw> okey dokey
17:06:08 <adamw> everyone to #fedora-bugzappers for some thrilling blocker review in two minutes
17:06:13 <adamw> or, you know, head for the yaks
17:06:18 * adamw sets fuse for two minutes
17:06:25 <adamw> it's a classical physics fuse this week!
17:06:57 <Viking-Ice> It should be done in QA or someother channel then bugzappers
17:07:42 <kparal> it should be done in #fedora-anythingelsethanbugzappers, right?
17:07:56 <Viking-Ice> I still say QA
17:08:04 <kparal> -1
17:08:10 <adamw> thanks folks
17:08:11 <Viking-Ice> but I accept  #fedora-anythingelsethanbugzappers as well
17:08:12 <adamw> #endmeeting