15:59:50 <jlaska> #startmeeting Fedora QA Meeting
15:59:50 <zodbot> Meeting started Mon Aug 24 15:59:50 2009 UTC.  The chair is jlaska. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:50 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:00 <jlaska> #topic gathering people
16:00:08 * kparal is here
16:00:26 <jlaska> howdy folks ... a few minutes for everyone to join ... and we'll kick things off
16:00:30 <adamw> howdy doodly
16:01:51 * tk009 stands-to
16:02:05 <lmr_> jlaska: I am here too :)
16:02:22 <jlaska> lmr_: howdy!
16:02:38 <jlaska> kparal: nanonyme: tkjacobsen: adamw: hey hey :)
16:02:45 <jlaska> s/tkjacobsen/tk009/
16:02:54 <jlaska> foiled by tab complete again
16:03:19 <nanonyme> Hey and thanks for inviting. Sounded interesting. :)
16:03:38 <jlaska> thanks for joining ... new ideas always welcome
16:04:21 <jlaska> I suspect wwoods and dpravec lurking in the shadows
16:04:43 <jlaska> wwoods might still be bear-proofing the cube
16:05:09 <jlaska> do we have Viking-Ice around as well?
16:05:14 <dpravec> yes i am here
16:05:19 <jlaska> dpravec: hey there!
16:05:24 <dpravec> :)
16:06:10 <jlaska> okay ... let's get moving and hopefully folks will join in soon
16:06:51 <jlaska> I don't have a lot on the agenda today ... mainly just recap on the Alpha, a slot fo autoqa updates, and some test day talk
16:06:55 <jlaska> see agenda @ https://www.redhat.com/archives/fedora-test-list/2009-August/msg00608.html
16:06:59 <jlaska> #topic Previous meeting follow-up
16:07:21 <jlaska> the only action item I captured was for me to sync up w/ Viking-Ice on the dracut testing
16:07:27 <jlaska> and I failed there :(
16:07:46 <jlaska> I'm building on the page I believe Viking-Ice drafted with guidance from harald
16:07:53 <jlaska> we can talk more about that in the test day section though
16:08:06 <jlaska> any other follow-up items from last week that were not covered?
16:08:34 * Oxf13 
16:08:36 <Oxf13> I'm here
16:08:38 <Oxf13> just got online here at the *$
16:08:43 <jlaska> Oxf13: howdy!
16:09:06 <jlaska> okay ... hearing silence on previous meeting  ... let's move into agenda
16:09:27 <jlaska> #topic F-12 post-alpha recap
16:09:38 <jlaska> so hopefully not getting ahead of myself by calling it post-alpha recap
16:09:57 <Oxf13> it would take an act of god to prevent us from releasing on Tuesday
16:10:01 <jlaska> but wanted to spend a few minutes on a mini post-mortem for the Alpha
16:10:12 <jlaska> Oxf13: yes, hopefully they stay up in their mountains
16:10:25 <jlaska> so ... let's start out with things that worked well
16:10:34 <jlaska> anyone want to volunteer?
16:10:50 <Oxf13> there was a ton more communication between releng and QA
16:10:55 <Oxf13> which was a great thing
16:11:35 <jlaska> Oxf13: yeah, I found it really helpful to hop onto those releng tickets that impacted us
16:12:06 <Oxf13> that's good, so that we get more value out of the tickets themselves.  Filing them is a bit of a pain
16:12:32 <jlaska> Oxf13: Liam's working out an issue with not getting email updates when he was on the ticket
16:12:42 <Oxf13> interesting!
16:12:50 <jlaska> Oxf13: but ideally, if we work out of the tickets, he can initiate test results as soon as bits are in hand
16:12:50 <Oxf13> it was his FAS name on the ticket?
16:13:08 <Oxf13> nod, I'll have to be better about touching the tickets as work progresses.
16:13:22 <Oxf13> last couple releases the work all ahappened, and then the tickets got mass closed after the fact
16:13:34 <jlaska> Oxf13: no worries, I think we policed ourselves on it for the alpha ... as long as you don't mind ... I'd like to keep doing that
16:14:14 <jlaska> another thing I felt worked well was the alpha blocker bug meetings
16:14:21 <adamw> i think the main area for improvement that presented itself is not in our processes but just the anaconda-sync-with-releases thing
16:14:24 <Oxf13> yeah, those were great
16:14:28 <Oxf13> as was the more detailed schedule
16:14:32 <adamw> i think most of our processes went off pretty well to be honest
16:14:45 <jlaska> adamw: thanks for bringing that up ... we discussed that briefly during one of the blocker meetings
16:15:04 <jlaska> how do folks feel about the current scheduling of blocker meetings
16:15:06 <adamw> yeah, we need to move it forward in some other venue but i haven't got enough round tuits yet :/
16:15:15 <jlaska> leading up to, during and after milestones
16:15:44 <adamw> the only thing i wonder about the scheduling is whether friday's the best day, since it means any problems we find may not be addressed for two or three days
16:15:55 <adamw> though we're pretty overloaded on other days of the week
16:16:14 <Oxf13> doing it on Friday means that those outside of US times get a jump start on work needed the next week
16:16:17 <jlaska> adamw: yeah I think that was the initial concern (if I could speak for poelcat) ... collissions with other events
16:16:24 <adamw> Oxf13: true
16:16:25 <jlaska> Oxf13: that's true too
16:16:46 <jlaska> Oxf13: speaking of, I requested that poelcat add another blocker bug date to the Beta
16:16:56 <jlaska> it would be right after we do some pre-TC testing
16:16:57 <Oxf13> ok
16:17:02 <Oxf13> sounds reasonable
16:17:11 <jlaska> cool
16:17:23 <jlaska> = okay ... things that could be improved =
16:17:30 <jlaska> * the test plan needs to be more agile
16:17:52 <jlaska> * current planned testing is only focused on installation
16:18:10 <jlaska> I don't get the warm feelings about other areas of the distro ... are there things we can be doing there
16:18:23 <jlaska> or do we feel the fedora-{devel,test}-list reports are sufficient?
16:18:44 <adamw> thinking only in an alpha context, the other major areas are networking and the yum/rpm stack, and xorg
16:18:54 <adamw> i think casual reports are likely to cover any major problems in networking and yum/rpm
16:19:05 <adamw> it's the kind of thing it's quite hard to miss if it's broken
16:19:32 <jlaska> true, there is a lot of value in having *many* eyes looking at this stuff
16:19:41 <adamw> xorg is tricky like anaconda as it's quite hardware dependent, but it might be nice to have a basic setup for testing at least if intel, nouveau and radeon aren't entirely broken
16:19:49 <Oxf13> I think we tend to focus on installer, because unlike the rest of the OS which has to be "testable", installer has to work in order to test other things
16:20:06 <Oxf13> so we provide the installer testing to make sure it can get installed, then rely upon users to cover the rest of the os as the Alpha is released
16:20:12 <adamw> and yeah, i agree with oxf13, the installer is easily the _most_ critical bit, because you're not going to be able to workaround it at all if it's broken
16:20:21 <adamw> with X you can at _least_ fall back on vesa or something
16:20:47 <jlaska> yeah ... all good points
16:20:59 <jlaska> testing the installer does touch on a quite a bit of these other areas too
16:21:10 <adamw> but with that caveat, if we have the hardware (i can cover nvidia and possibly radeon at a push) we could have a little xorg table in there
16:21:32 <Oxf13> nod
16:21:39 <jlaska> I'm open to trying it for the Beta ... if it doesn't work ... no harm done
16:21:52 <wwoods> little xorg table in where?
16:22:04 <adamw> well something like the install text matrix
16:22:16 <adamw> whether it goes on the same page or not i dunno
16:22:18 <wwoods> ensuring basic functionality of intel/nouveau/radeon is supposed to be part of the rawhide acceptance plan
16:22:38 <wwoods> https://fedoraproject.org/wiki/QA:X_basic_display_test_case
16:22:42 <Oxf13> we don't have tables for it though do we?
16:22:49 <adamw> well, so is testing the installer works, but we have a table and manual testing for that too :)
16:23:01 <wwoods> so possibly the test matrix just lacks boxes for the test cases from the rawhide test plan
16:23:06 <jlaska> wwoods: oh that's right
16:23:11 <adamw> Oxf13: the idea being that we write one :) it could just be 3x1, heh
16:23:33 <adamw> wwoods: the current matrix is specifically labelled an _install_ test matrix iirc
16:23:46 <wwoods> and also https://fedoraproject.org/wiki/QA:Rawhide_Acceptance_Test_Plan#Basic_Functionality
16:23:48 <jlaska> adamw: for installer ... we have a few tests to confirm that if something does break ... the methods of recovery function (updates= and rescue-mode)
16:23:59 <wwoods> right but the install test plan is predicated on QA accepting the bits for testing at all
16:24:03 <jlaska> adamw: is that worth noting for Xorg too (re: vesa, nomodeset)
16:24:14 <wwoods> which is what the acceptance test plan is supposed to decide
16:24:46 <wwoods> anyway without getting too deep into the meanings of Acceptance Testing and other overly-formal QA junk
16:25:12 <wwoods> the stuff from the rawhide acceptance test plan needs to be considered part of (or a prerequisite to) the installer plan
16:25:30 <jlaska> wwoods: good point
16:25:39 <wwoods> and thus needs a test result matrix of its own (or spaces in the installer matrix)
16:26:01 <adamw> doing it that way is fine by me
16:26:10 <wwoods> and actually the israwhidebroken.com plan involves having a place for manual test results for that specific test
16:26:40 <wwoods> but yeah, the installer plan needs to have a note that says "see also these results over here"... once we're properly collecting those results.
16:26:52 <jlaska> wwoods: that's something to consider ... if we don't have that bit in place yet ... perhaps having some stop-gap on the wiki for the beta would be acceptable?
16:27:06 <jlaska> https://fedoraproject.org/wiki/Category:Fedora_12_Test_Results
16:27:15 <jlaska> anchored under ^^^ or a sub-category of that
16:27:23 <jlaska> okay ... any other points to note about the Alpha
16:27:26 <jlaska> Good/bad/ugly?
16:28:41 <jlaska> #action jlaska to talk with Liam about how we can make the current install test plan more attainable
16:28:49 <jlaska> any other items to capture on this topic?
16:29:43 <adamw> nothing from me
16:29:46 <jlaska> #action include a xorg-x11-drv matrix in F-12-Beta test matrix for nouveau, intel and radeon
16:30:06 <jlaska> #topic autoqa update from wwoods
16:30:29 <jlaska> alrighty ... wwoods I've got the always present slot in the meeting for any updates or help needed on the autoqa front
16:30:53 <wwoods> okay so.. the autoqa stuff is still happening automatically. whee!
16:31:04 <jlaska> yeah, holy emails batman! :)
16:31:12 <wwoods> I fixed up the conflicts test - it was doing Obsoletes and Conflicts wrong, and taking 5 hours to run
16:31:41 <wwoods> cleaned up the email subjects too, so it's a lot easier to figure out the results
16:31:51 <wwoods> e.g. "repoclosure: 34 packages with unresolved deps in rawhide-x86_64"
16:32:01 <jlaska> wwoods: that conflicts change seems to have done the trick
16:32:16 <Oxf13> yeah that's good stuff
16:32:30 <Oxf13> next we need somebody to start consuming that info (:
16:32:31 <wwoods> the rats_* tests were broken over the weekend but I've (mostly) fixed them
16:32:41 <Oxf13> but we're getting there
16:32:44 <wwoods> rats_install seems to take a lot longer than it should
16:33:02 <wwoods> and rats_sanity mysteriously does not work on i386 rawhide
16:33:10 <jlaska> wwoods: I'm waiting on a PXE change for that new kms SDV workstation ... will add it to autotest once I hear back
16:33:15 <wwoods> might be a yum bug, I need to talk to skvidal
16:33:28 * skvidal looks up
16:33:56 <wwoods> anyway, I rewrote the option-parsing code in the autoqa harness to be more sane (i.e. not hardcoding hook-specific code in the main harness)
16:34:04 <wwoods> merged the autotest branch into master
16:34:18 <wwoods> and this week I'll mostly be documenting how to write new tests and implement new hooks
16:34:39 <wwoods> and trying to figure out how we can get other automated systems to consume the test results
16:34:43 <Oxf13> wwoods: a new autotest was released upstream, and I think it includes support for django 1
16:34:54 <Oxf13> when would be a good time to update to the new version and throw it at you?
16:35:01 <wwoods> Oh nice - is that what we have in Fedora, then?
16:35:22 <wwoods> jlaska: do we have a spare system / capacity for a virt guest to try that out on?
16:35:31 <jlaska> wwoods: we could do a spare guest
16:35:39 <Oxf13> we don't have the new autotest anywhere
16:35:40 <dpravec> i can test it
16:35:43 <jlaska> Oxf13: might be a good time to check back in on the packaging
16:35:45 <Oxf13> but django 1 is what we have in Fedora
16:35:51 <jlaska> Oxf13: once we're good on the packaging, I'm going to setup qa1
16:35:56 <Oxf13> ok
16:35:58 <dpravec> 1.1 is imho actual django release
16:36:06 <jlaska> Oxf13: last we left it ... the packaging was fairly solid
16:36:29 <Oxf13> jlaska: indeed, I think it got reviewed and approved
16:36:49 <jlaska> awesome, thanks for pushing on that front
16:36:50 <Oxf13> or would be as soon as we figure out the stupid google web toolkit crap
16:37:21 <dpravec> Oxf13: so, please package it rather soon
16:37:40 <Oxf13> dpravec: I can't until gwt is figured out
16:37:51 <jlaska> Oxf13: this is for Fedora you mean?
16:37:57 <Oxf13> right, for Fedora
16:38:01 <jlaska> and not just the fedora-infra repor
16:38:03 <Oxf13> I can do a new build of the new version
16:38:12 <Oxf13> and get it into the infra
16:38:15 <jlaska> worth a shot ... and wwoods and I will test that out
16:38:21 <Oxf13> nod
16:38:23 <dpravec> i can test too
16:38:27 <Oxf13> I'll put that on this week's to do list
16:38:47 <jlaska> #action f13 updated autotest-0.11 build
16:38:48 <Oxf13> #action Oxf13 will do a build of the new autotest version for testing.
16:38:59 <adamw> so, a question: aren't we now at the point where we could actually create the much-vaunted israwhidebroken.com ?
16:39:04 <jlaska> #action jlaska + wwoods to test latest autotest build
16:39:17 <dpravec> adamw: soon, soon :)
16:39:35 <adamw> wwoods: is that on your schedule? it seems like the necessary tests for it to happen are now in place and running
16:39:46 <adamw> (which is awesome)
16:40:23 <wwoods> adamw: close. we need a way to pull/push data from autotest to fill in the boxes for the automated parts
16:40:31 <adamw> i see
16:40:52 <wwoods> and then we need an (authenticated) way for qa team people to fill in the boxes for unautomated bits (e.g. Xorg)
16:41:48 <adamw> i think we could start doing the page even without that bit and add it on later
16:41:51 <wwoods> so as I said earlier, the two big items I have for this week are to look into that (pulling/pushing data from autotest for e.g. israwhidebroken.com)
16:42:02 <adamw> just whether the automated tests pass or not on a given day is useful enough in its own right
16:42:17 <dpravec> yes
16:42:19 <wwoods> and writing docs so petr / dpravec / et. al. can get their hands dirty designing new tests/hooks, like Fedora TPS and such
16:42:29 <adamw> gotcha
16:42:42 <wwoods> we already have daily automated results on the autoqa-results list
16:42:42 <jlaska> whole lotta bootstrapin' going on
16:43:04 <wwoods> that's the stopgap until the other bits get glued together
16:43:47 <adamw> brb, call of nature - i do have an open floor topic so don't stop without me :)
16:43:53 <jlaska> wwoods: awesome work, thanks for the updates!
16:43:55 <jlaska> adamw: okay
16:44:05 <wwoods> jlaska: thanks, and no problem
16:44:06 <jlaska> wwoods: any other points ... or should we move on?
16:44:50 <jlaska> alrighty ... moving on to next topic ...
16:45:07 <jlaska> #topic Test Day updates - fedora-test-announce?
16:45:28 <jlaska> dpravec you mentioned this the week prior, but I neglected to add it to the agenda
16:46:06 <dpravec> i heard people telling me that they would love to participate some test days
16:46:15 <dpravec> but they do not read many maillists
16:46:29 <dpravec> for example one said he reads only fedora-announce
16:46:34 <dpravec> and others only ocassionally
16:46:42 <adamw> i do announce them also on fedora planet and the forums
16:46:51 <adamw> they're really not important enough to go to fedora-announce
16:46:52 <dpravec> and we cannot announce tests on fedora-announce
16:46:56 <jlaska> btw ... this is a topic that comes up a lot ...
16:46:57 <jlaska> https://fedoraproject.org/wiki/Fedora_11_Test_Day_Survey#Advertising
16:47:00 <dpravec> so it makes sense to make list fedora-test-announce
16:47:08 <dpravec> for people who would like to test some things
16:47:15 <adamw> ones with a wider interest we sometimes promote to news sites, but we can't do that for ones which are really of interest specifically to fedora
16:47:19 <dpravec> and who do not want to miss fav app test day
16:47:28 <dpravec> but who do not want much traffic
16:47:58 <dpravec> so i think we should create and use maillist    fedora-test-announce
16:48:05 <dpravec> which will be used only for announcing test days
16:48:21 <adamw> not a bad idea...
16:48:26 <adamw> well, we could announce other things there too
16:48:29 <Oxf13> Would it make sense to just re-use fedora-devel-announce ?
16:48:35 <dpravec> yes, just low traffic one
16:48:37 <adamw> test composes, alpha slips
16:48:38 <Oxf13> I'm never really in favor of more mailing lists
16:48:45 <adamw> Oxf13: i think there might be value in a separate list
16:48:50 <dpravec> fedora-devel-announce is for developers
16:48:52 <jlaska> Oxf13: it was requested I stop posting test days to fedora-devel-announce during F11
16:48:52 <tk009> agree with 0xf13
16:48:54 <dpravec> test could be for endusers
16:49:14 <Oxf13> *shrug*
16:49:21 <jlaska> Oxf13: yeah :)
16:49:28 <Oxf13> just make sure to do the same thing and subscribe fedora-test-list to fedora-test-announce
16:49:44 <Oxf13> so that those of us on the rather quiet fedora-test-list can still get the announcements.
16:49:50 <jlaska> Oxf13: ah good point
16:50:07 <jlaska> fedoraproject.org  has it's own mailman now right?
16:50:14 <Oxf13> yeah
16:50:18 <Oxf13> lists.fedoraproject.org
16:50:36 <jlaska> dpravec: do you want to handle creating the list or looking for someone else to grab that?
16:50:51 <dpravec> hmm can i create it?
16:51:11 <jlaska> I think you can request one ... https://admin.fedoraproject.org/mailman/listinfo
16:51:14 <dpravec> i think i am not an admin of the mailman
16:51:23 <dpravec> ok
16:51:27 <Oxf13> you can file the ticket to get a new one (:
16:51:27 <dpravec> i will do it
16:51:33 <jlaska> Oxf13: ah thanks
16:51:44 <dpravec> ticket? where?
16:51:56 <jlaska> dpravec: https://fedorahosted.org/fedora-infrastructure/report
16:52:01 <jlaska> perhaps try there?
16:52:01 <dpravec> ok
16:52:18 <jlaska> dpravec: nice suggestion, thank you!
16:52:43 <jlaska> #action dpravec to investigate creating fedora-test-announce mailing list for Test Days, other test events, schedule updates
16:52:57 <jlaska> okay next up ...
16:53:05 <jlaska> #topic Test Day updates - fit'n'finish printing
16:53:24 <jlaska> just real quick here ... I didn't see how this event went
16:53:41 <jlaska> has anyone had a chance to chat w/ mclasen?
16:53:49 <Oxf13> not about this
16:54:22 <adamw> me either, but i was around for some of the day, seemed to be going well
16:54:35 <adamw> mostly 'internal' - the fnf guys and the printing guys - but a few other testers did drop by
16:54:43 <jlaska> adamw: okay ... I'm hoping the format is still working to his benefit
16:55:15 <jlaska> #topic Test Day updates - ABRT
16:55:32 <jlaska> another recap from last week
16:55:43 <jlaska> thanks dpravec and kparal for your efforts!
16:55:45 <jlaska> https://www.redhat.com/archives/fedora-test-list/2009-August/msg00609.html
16:56:19 <dpravec> it was a pleasure.
16:56:25 <jlaska> jmoskovc was quite pleased with the feedback this time
16:56:28 <dpravec> you are welcome :)
16:56:48 <jlaska> okay ... now for this weeks event ...
16:56:51 <adamw> good job on the post-report email too
16:56:58 <adamw> er, post-event email report :)
16:56:59 <jlaska> +1
16:57:04 <dpravec> ty adamw...  btw your script worked
16:57:10 <dpravec> but maybe , if i can
16:57:17 <jlaska> #topic Test Day updates - 2009-08-27 Dracut
16:57:18 <adamw> don't dignify it with the name 'script' =)
16:57:31 <jlaska> dpravec: adamw is l33t
16:57:42 <dpravec> uff, so later in open arena
16:57:52 <adamw> you could turn it into one quite easily, so you could feed it a date and it'd grab the page without you having to bother
16:57:55 <adamw> i'm just too lazy to do it
16:58:09 <dpravec> jlaska: i can has script too
16:58:40 <jlaska> just a quick update on the dracut test day ...
16:58:42 <jlaska> #link https://fedoraproject.org/wiki/Test_Day:2009-08-27#Test
16:59:05 <jlaska> the 3 core test cases are already defined ... and I'm trying to organize the remaining data points harald wants feedback on around those
16:59:12 <jlaska> e.g. the different root= scenarios
16:59:24 <jlaska> hopefully will have a fair bit of that done this afternoon and ready for announce
16:59:53 <jlaska> if anyone has ideas or suggestions for improvement ... feel free to ping me after the meeting
17:00:28 <jlaska> the big thing is that harald just wants people to show up and either boot their F-11 systems using dracut ... or boot the live image ... and report back
17:00:48 <jlaska> #action jlaska will cleanup remaining test cases for dracut and send announcement
17:01:02 <jlaska> okay ... let's move on to open discussion ...
17:01:15 <jlaska> #topic open discussion - <your topic here>
17:01:18 <adamw> alright, quickly:
17:01:23 <jlaska> adamw: go for it
17:01:27 <adamw> #topic nightly live builds
17:01:35 <adamw> grr, i have no power! you do it :)
17:01:36 <jlaska> #chair adamw
17:01:36 <zodbot> Current chairs: adamw jlaska
17:01:42 <adamw> #topic open discussion - nightly live builds
17:02:00 <adamw> i think the nightly live builds are awesome and need to be widely heralded
17:02:07 <jlaska> excellent point
17:02:10 * nirik looks up.
17:02:18 * jlaska prepares the trumpet
17:02:23 <adamw> so i added a chunk to the rawhide wiki page about them - https://fedoraproject.org/wiki/Releases/Rawhide#Nightly_live_builds - and am going to try and spread the news to some news sites
17:02:26 <adamw> nirik: you rock!
17:02:37 <nirik> yeah, I haven't had time to do anything there. If someone wants to advertise, please feel free. ;)
17:02:43 <adamw> what would be great is if others could spread the word too
17:02:56 <adamw> if you blog, blog about it (you can just link to my blog post which will go up soon, or the wiki page, or whatever)
17:03:02 <adamw> tweetie-pie it
17:03:04 <Oxf13> please be aware
17:03:07 <adamw> mention it on appropriate mailing lists or whatever
17:03:13 <Oxf13> the more people you point at th enightly builds, the less people are going to be able to download them
17:03:16 <adamw> just want to make sure we have the word out about it
17:03:19 <kparal> how is it possible that it has x86_64 build when there is no x86_64 packages in rawhide repositories available in the last few days?
17:03:22 <Oxf13> they are not mirrored, so this is a single point of resources
17:03:28 <adamw> Oxf13: if we start hitting capacity problems, we can try and provide more download resources
17:03:30 <Oxf13> kparal: pardon?
17:03:40 <Oxf13> adamw: that box is almost always at capacity
17:04:01 <Oxf13> continuing to point large amounts of people to a single download source for large isos is just doing it wrong.
17:04:01 <kparal> Oxf13: maybe our local brno mirror problem, but for the last few days in rawhide repo there is only i386 stuff
17:04:04 <jlaska> Oxf13: adamw: mmcgrath has been helping to monitor any access issues for the stage url ... this is on the same box right?
17:04:13 <Oxf13> jlaska: yes, same box
17:04:13 <adamw> Oxf13: i don't think there's much point in having nightly builds but not telling anyone about them because we don't have the capacity to serve them
17:04:18 <Oxf13> I think.
17:04:24 <Oxf13> nirik: the isos are being put on secondary1 right?
17:04:26 <adamw> it's just a waste of generation time if we're going to have to 'hide' them like that...
17:04:35 <nirik> Oxf13: yep.
17:04:36 <Oxf13> adamw: ti's the classic live problem
17:04:47 <Oxf13> A) they're big.  B) they don't rsync well against older isos
17:04:54 * nirik doesn't know the solution here, but is happy to do whatever he can to make them more accessable.
17:05:10 <nirik> would deltaisos help any?
17:05:15 <Oxf13> adamw: it's not a waste of generating them when automated tests can be ran on them, discovering things like size changes, package listing changes, etc...
17:05:16 <Oxf13> nirik: no
17:05:25 <Oxf13> nirik: live images are just an iso of one big squashfs file
17:05:47 <nirik> yeah. I haven't looked at how deltaisos work or if they would do any good here.
17:05:54 <dpravec> kparal:  i see 1260 packages on nfs...
17:05:57 <adamw> Oxf13: well, to put it less negatively: there is a considerable potential benefit in having them widely available and it would be a shame to lose that due to resource issues which ought to be solveable
17:06:03 <dpravec> s/1260/18260/
17:06:05 <jlaska> let's keep on using them ... and if we start to have problems getting them ... we can escalate with the infrastructure team
17:06:16 <nirik> so whats the solution? mirror them?
17:06:20 <Oxf13> adamw: so I question this
17:06:33 <Oxf13> adamw: what added benefit over rawhide do the live images have
17:06:34 <dpravec> aha, those are 08-19
17:06:39 <adamw> Oxf13: testable without installing
17:06:45 <Oxf13> that would be worth the resource costs to provide them on a single download source
17:06:54 <adamw> that's big enough all on its own
17:07:03 <Oxf13> adamw: every single day?
17:07:17 <Oxf13> would not weekly provide the same value?
17:07:22 <adamw> every day is good. weekly would work nearly as well.
17:07:29 <Oxf13> (you know, like the weekly snapshots we're going to be doing, and putting on torrents)
17:07:37 <adamw> if weekly push is sufficient to address the bandwidth issue it's a compromise i could live with.
17:07:46 <adamw> i was not aware of the weekly torrent plan. where's that documented?
17:07:48 * nirik doesn't care about weekly, but it was just easier to push them everytime they were composed.
17:07:53 <jlaska> nightly live images might be a future benefit wecan offer for QA group membership
17:08:18 <Oxf13> adamw: snapshot 1,2,3 have been in the schedule since the beginning
17:08:31 <Oxf13> which are snapshots during the weeks between Alpha and Beta
17:09:01 <Oxf13> the big motivation for having nightly live images was to track issues with composing
17:09:02 <jlaska> let's wrap up this topic ...
17:09:10 * dpravec is having #topic bugzilla testday + testcase
17:09:10 <Oxf13> mainly size changes and new dep issues
17:09:11 <jlaska> does someone want to propose a different delivery mechanism for the live images?
17:09:20 <adamw> Oxf13: that's not really the same thing. it's only happening at a specific point in the cycle
17:09:30 <adamw> we didn't do weekly images pre-alpha, the schedule doesn't show them post-beta either
17:09:59 <adamw> unless it's changing for f13, if you look at the f12 cycle, from the start of f12 development until the first alpha test compose, there's no live image build scheduled
17:10:03 <Oxf13> adamw: that's because the rate of change then is supposed to be small, so using the last point release and yum updating will get you the same state
17:10:05 <dpravec> jlaska: iam all for bittorent...
17:10:19 <dpravec> but thats not useable in some companie
17:10:19 <adamw> Oxf13: which you can't do live, practically speaking.
17:10:24 <Oxf13> excuse me?
17:10:33 <Oxf13> you most certainly can
17:10:38 <jlaska> okay gang
17:10:41 <adamw> Oxf13: not if you need to test a kernel update...
17:10:43 <Oxf13> outside of say the kernel
17:10:45 <adamw> =)
17:10:50 <adamw> (or, practically speaking, udev)
17:10:53 <Oxf13> which at this point really shouldn't be changing
17:10:58 <Oxf13> or that point I should say
17:11:04 <adamw> and pre-alpha?
17:11:21 <Oxf13> pre-alpha you're going to be lucky to get a working live image one a week, let alone once a day
17:11:30 <dpravec> heh, true
17:11:32 <Oxf13> my point is that it's a giant waste of resources
17:11:46 <Oxf13> for some benefit, but at a huge cost
17:12:02 <jlaska> Oxf13: whose resources are they?
17:12:11 <Oxf13> we should be aware of the costs here and not just shrug and say "eh, we'll fix it whenever infra runs out of bits"
17:12:22 <Oxf13> jlaska: bandwidth and disk IO
17:12:22 <jlaska> Oxf13: is this infrastructure team?
17:12:34 <jlaska> Oxf13: sorry, I meant who manages this and is responsible for it
17:12:38 <Oxf13> as well as tester bandwidth thinking they need to download a new live image every day
17:13:02 <Oxf13> Infrastructure is ultimately responsible
17:13:37 <jlaska> then lets talk to the experts so they can work up a solution or advise that this isn't doable with current resources?
17:14:03 <jlaska> I'll be happy to take this for next week ... unless someone else would like it?
17:14:08 <Oxf13> yes, we should talk to them
17:14:16 <Oxf13> but they really are too nice, they'll just let you consume everything they have (:
17:14:52 <jlaska> Oxf13: no ... last we discussed, they identified a threshold for bandwith for the RC images
17:15:00 <jlaska> and we talked about some possible next steps
17:15:38 <jlaska> #action jlaska to discuss bandwith implications of hosting nightly rawhide live images with fedora-infrastructure
17:15:44 <jlaska> #chair dpravec
17:15:44 <zodbot> Current chairs: adamw dpravec jlaska
17:15:59 <jlaska> dpravec: did you have a topic to discuss?
17:16:04 <dpravec> my next topic is related to bugzilla and test days
17:16:19 <jlaska> #topic open discussion - bugzilla and test days (dpravec)
17:16:28 <dpravec> we need to get rid of tables with bug descriptions and links to bugzilla
17:16:41 <dpravec> do not repeat yourself (DRY) is important principle to be kept
17:16:54 <dpravec> it would be best to have own fields in bugzilla
17:17:02 <dpravec> TestCase  and TestDay
17:17:20 <dpravec> which can be prefilled when you click near testace on 'report bug on this testcase'
17:17:34 <dpravec> so we can have everything live in bugzilla
17:17:58 <dpravec> i am not sure how to achieve this... but i would love to stop writing bugz into tables in wiki
17:18:03 <adamw> as i said when we discussed this before, we do have a results table layout for test days which is not a simple list of bugs
17:18:16 <dpravec> adamw: testcase could be a field
17:18:22 <dpravec> so you can get nice table from bugzilla
17:18:31 <dpravec> at least if i imagine it right
17:18:36 <dpravec> i am not using it for long
17:18:42 <dpravec> so i need help there
17:18:45 <adamw> see e.g. https://fedoraproject.org/wiki/Test_Day:2009-03-26_Nouveau#Results
17:18:54 <adamw> i think that may be possible _in theory_ but in practice would be rather complex...
17:19:04 <adamw> for a start we try to avoid non-trivial bugzilla customizations wherever possible
17:19:23 <jlaska> and bugzilla itself is fairly stand-off-ish for noobs
17:19:32 <adamw> you could have TestDay and TestCase keywords, but they have to be added to Bugzilla itself and i imagine it'd be a pain for the bz admins to do that every week
17:19:35 <dpravec> yes, but that is my another topic :)
17:19:43 <dpravec> (noobs x bugzilla)
17:19:50 <adamw> you could (ab)use the whiteboard space, but i'm not sure that can be pre-filled in a 'file a bug' link
17:19:55 <adamw> have to test that
17:20:08 <dpravec> we need to look out for solution
17:20:16 <adamw> there's also the rather tricky case that defining pass/fail is somewhat subjective and best left to humans
17:20:26 <jlaska> I think it's important to note that the wiki is our interim solution
17:20:33 <adamw> sometimes a human can see quite easily that a test _basically_ passed but there's a little problem with it
17:20:41 <adamw> so they list the test as a PASS but with a footnote link to a bug report
17:20:45 <adamw> it'd be a bit tough to automate that
17:20:51 <jlaska> there are other options out there ... and maybe some quick fixes to make the short-term more useful
17:21:00 <adamw> yep, that is also important: you mentioned a test case management system, we don't have one yet but we _want_ one :)
17:21:34 <dpravec> hmm we need a good test case management system...
17:21:38 <wwoods> see also: pony
17:21:48 <dpravec> pony?
17:21:49 <jlaska> for the sugar on a stick test day ... mchua and sdziallas were intending to demo semantic+mediawiki
17:21:52 <adamw> i think there's a good test case management system inside every pony
17:22:03 * sdziallas is here, waves.
17:22:33 <sdziallas> jlaska: we're going for test cases at the moment... I created a wiki page about the day in general, but it still needs a lot of content from my side.
17:23:09 <lmacken> ooo... good liveusb-creator testing can come out of that too :)
17:23:47 <dpravec> pony=?
17:23:49 <wwoods> dpravec: heh, like "daddy, I want a pony" - just the standard joke for any time we start talking about things that everyone wants, but nobody actually has the time/money/skill to make it happen
17:23:56 <adamw> dpravec: it's a running geek/fedora joke
17:24:05 <dpravec> eh :)
17:24:16 <adamw> dpravec: the idea being that everyone wants something big and cool and awesome but doesn't think about the work involved in getting it
17:24:19 <adamw> thus 'i want a pony!'
17:24:22 <wwoods> http://i-want-a-pony.com/
17:24:28 <dpravec> ok, i will start thinking how to acquire a pony for you :)
17:24:32 <jlaska> wwoods: awesome!
17:24:38 <nanonyme> Ponies mentioned. :)
17:25:07 <jlaska> dpravec: I'm always interested in simple improvements to the current wiki experience
17:25:09 <dpravec> oh i think i have seen it on some django presentation :)
17:25:26 <jlaska> dpravec: yeah, that's not available to us yet
17:25:29 <dpravec> hey but this can be easy
17:25:42 <dpravec> we do not need an elephant
17:26:06 <lmacken> dpravec: that's because django is the webframework for magical ponies with super powers :)
17:26:17 <adamw> dpravec: as jlaska said, if you can suggest a practical fairly easy change to the current wiki system, we're all ears - there's nothing set in stone about it, it's just something i bashed out a few months ago :)
17:26:20 <dpravec> i will try to some people about it and next week i will tell you if i can get a pony
17:26:55 <dpravec> to talk*
17:27:00 <jlaska> okay ... let's wrap things up for today
17:27:24 <jlaska> jlaska bot self destructs after a 1.5 hour meeting
17:27:29 <dpravec> i love animals :)
17:27:35 <jlaska> dpravec: haha
17:27:51 <jlaska> okay gang ... anything else that can be said in 30 seconds ?
17:28:06 <dpravec> i will keep that for next week :)
17:28:08 <adamw> i hate gigabyte!
17:28:12 <adamw> sorry, needed to get that out of my system =)
17:28:13 <nanonyme> Btw, one question: how much locked up is Rawhide atm? Kernel driver features put on freeze?
17:28:33 <jlaska> nanonyme: I believe the flood gates are open again
17:28:39 <wwoods> not for features
17:28:42 <wwoods> just for builds
17:28:52 <jlaska> nanonyme: yes, as wwoods said
17:28:53 <nanonyme> Right...
17:29:03 * nirik upgraded his laptop to rawhide this weekend. Went very smoothly.
17:29:28 <jlaska> 40 seconds till detonation ...
17:29:35 * dpravec upgraded to testing, with kde 3.0
17:29:38 <nanonyme> Just wondering if KMS parts or 3D parts of DRM for new ATi cards would get into the release. Probably not?
17:29:41 <dpravec> eh 4.3.x
17:29:58 <adamw> nanonyme: they're probably in there already, fedora kernel runs ahead of upstream in that respect.
17:30:04 <dpravec> jlaska: happy post-detonation :)
17:30:15 <adamw> nanonyme: if not yet they almost certainly will be, graphics stuff is generally pushed in quite late, right up to beta freeze.
17:30:56 <adamw> nanonyme: i believe kms for later radeons has been in for a while but is disabled by default for safety, you can force radeon.modeset=1 to test it. not sure if that's changing for f12, have to check with airlied.
17:30:58 <nanonyme> adamw: 3D parts are in one developer's own DRM git tree, current KMS parts are just getting looked through by airlied.
17:31:22 <adamw> nanonyme: ok. as i said, graphics stuff generally keeps getting pushed in till quite late, i'd be surprised if they stop updating it now.
17:31:28 <jlaska> okay folks ... let's close it out for today
17:31:29 <nanonyme> adamw: The thing in Rawhide can't do X atm but I've heard what the developers have is further.
17:31:33 <jlaska> we can continue over in #fedora-qa and on the list
17:31:33 <nanonyme> Right. Thanks.
17:31:37 <jlaska> thanks everyone for your time!
17:31:54 <adamw> nanonyme: you can always ask airlied directly if you find him active, he doesn't bite :)
17:31:56 <jlaska> #endmeeting