16:01:56 <adamw> #startmeeting Fedora QA meeting
16:01:56 <zodbot> Meeting started Mon Nov 26 16:01:56 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:56 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:58 <adamw> #meetingname fedora-qa
16:01:58 <zodbot> The meeting name has been set to 'fedora-qa'
16:02:02 <adamw> #topic roll call
16:02:06 * kparal is here
16:02:07 * tflink is here
16:02:12 * Cerlyn_ is here
16:02:15 * maxamillion is here
16:02:24 * adamw is barely here
16:02:34 * satellit_e listening
16:02:40 <tflink> adamw: that's what coffee's for :)
16:02:54 <adamw> mmm, glorious coffee.
16:03:06 * mkrizek is here
16:03:08 * jreznik_n9 is not available today... day off
16:03:27 <maxamillion> adamw: +1
16:03:36 <adamw> .fire jreznik
16:03:36 <zodbot> adamw fires jreznik
16:03:58 <adamw> #topic previous meeting follow-up
16:04:14 <adamw> alright, a nice batting practice fastball for tflink here...
16:04:23 <tflink> uh oh
16:04:44 <adamw> ...just as soon as i can get to the wiki.
16:05:01 <adamw> "tflink to continue to evaluate fedup status and propose significant bugs for blocker status"
16:05:28 <tflink> oh, yeah. that is done for the time being
16:05:44 <tflink> fedup still has some rough edges but in general, it seems to be working
16:06:15 <adamw> we've managed to keep the victims' families away from the press, so all is well
16:06:17 <kparal> will we have some upgrade documentation in time for Beta release?
16:06:28 <tflink> yeah, that's on my todo list for today
16:06:28 <jreznik_n9> rough edges...
16:06:45 <adamw> #info  "tflink to continue to evaluate fedup status and propose significant bugs for blocker status" - this was done, fedup has rough edges but is basically working
16:06:59 <tflink> either will, I or the docs team will get something done before beta is released tomorrow
16:07:02 <jreznik_n9> we also need a todo list for final
16:07:18 <tflink> finishing the test plan and more test cases would be good, too
16:07:22 <adamw> kparal: i mailed docs list to ask them to look after it, jack reed said he will do it
16:07:25 <jreznik_n9> to be on the same side of force
16:07:33 <adamw> "I will keep in touch with Will and tflink to ensure fedup is documented
16:07:33 <adamw> accurately."
16:07:34 * pschindl is late, but here
16:07:37 <adamw> not sure if he meant for beta, though
16:07:51 <adamw> #info docs team taking care of fedup documentation, but not sure if they'll be ready for beta
16:08:08 <adamw> #action tflink to ensure some kind of upgrade documentation is ready for beta availability tomorrow
16:08:22 <adamw> since we're already on it anyway...
16:08:23 <tflink> yeah, that was the impression I got too. not sure if the docs would be done for beta release
16:08:23 <kparal> in the CommonBugs page I referenced http://fedoraproject.org/wiki/Upgrading a few times
16:08:34 <adamw> #topic Fedora 18 Beta review / Final planning
16:08:48 <adamw> oh, you started on commonbugs? awesome, thanks
16:09:14 * tflink makes note to update that page
16:09:44 <adamw> #info commonbugs needs updating for various beta bugs, kparal already made a start
16:10:09 <adamw> for anyone else who wants to help out - the page is https://fedoraproject.org/wiki/Common_F18_bugs , see the comments for instructions and style guide, and compare to existing entries
16:10:21 <jreznik_n9> especially nfs thing has to be mentioned
16:11:05 * jreznik_n9 could go through the page tmrw in the morning for final review, touches
16:11:25 <adamw> please, everyone who has something to contribute, do :)
16:11:34 <adamw> and make sure any significant bugs are tagged with the CommonBugs keyword
16:12:20 <adamw> anything else anyone is worried about for beta?
16:14:02 <tflink> I'm a little worried about fedup for beta but a lot of that is due to the change from preupgrade/DVD
16:14:12 <tflink> I think there are going to be a lot of questions
16:14:30 <adamw> i think that was pretty inevitable
16:14:43 <adamw> i'll try and stay on top of the forums, any help welcome
16:14:54 <adamw> the other thing we could do is make sure the folks from #anaconda and user-list are briefed
16:15:10 <adamw> do you want to do that, once we have the docs in place, or should i?
16:15:33 <tflink> briefed? on where the docs are?
16:15:53 <tflink> I can do the coordination on fedup docs, though
16:15:58 <tflink> do/help with
16:16:33 <adamw> yeah, just let them know fedup is landing, here are the docs, you might want to try it out so you know what you're talking about to help people, here's who to ask if you get stuck
16:16:38 <adamw> that kinda thing
16:18:09 <tflink> ok, I think that finding a few #fedora regulars would be wise as well
16:18:41 <adamw> d'oh, that's what I meant, not #anaconda obviously :)
16:18:57 <adamw> #info tflink to brief #fedora ops and fedora-user-list regulars on fedup
16:18:59 <adamw> grr
16:19:00 <adamw> #undo
16:19:00 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xa3f77d0>
16:19:04 <adamw> #action tflink to brief #fedora ops and fedora-user-list regulars on fedup
16:19:21 <adamw> ok, anything else on beta?
16:19:45 <tflink> other than bracing myself for final testing, nothing from me :)
16:20:09 <maxamillion> heh ... I apparently hit "pageup" and irssi scrolled up but then I didn't notice and was staring at an earlier part of the convo thinking to myself "this meeting seems slower than usual" .... /me facepalms (sorry for the offtopic, just had to share)
16:20:41 <adamw> that's the kind of top-quality staff we at rh insist on, folks
16:20:49 <maxamillion> >.>
16:20:56 <maxamillion> \o/
16:21:04 <adamw> (says adamw from his dining table, in dressing gown, with cat at his side)
16:21:12 <maxamillion> adamw: I don't even have a good excuse
16:21:34 <adamw> ok, so for final planning
16:21:48 <adamw> since i know everyone loves them so much, i was thinking we could indulge ourselves and start blocker review this week
16:21:59 <tflink> yeah, I was thinking the same thing
16:22:16 <adamw> i mean i know it barely seems worth it with the tiny final blocker list - http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist - but still...
16:22:17 <adamw> (dies)
16:22:18 <tflink> just to at least start getting through the huge list we have thus far
16:22:40 <adamw> so who's ready for some exciting blocker review on wednesday?
16:22:49 <maxamillion> o/
16:23:30 <tflink> maxamillion: says a guy who doesn't regularly show up for the review meetings :-D
16:23:45 <maxamillion> tflink: I know :( ... I've been terrible at that this release
16:23:50 <adamw> i think he probably just facepalmed on the keyboard again.
16:24:05 <tflink> how do you facepalm on the keyboard?
16:24:05 <maxamillion> silly $dayjob keeps getting in the way
16:24:26 <adamw> tflink: it takes skills, to be sure.
16:24:57 <adamw> okay, the other thing we have is the Final TC date
16:25:09 <adamw> #info first Final blocker review meeting this Wednesday, 11-28
16:25:12 <tflink> do we still have test cases and/or criteria to revise for final?
16:25:19 <adamw> yes, i have a topic coming up for that next
16:25:28 <tflink> ok
16:25:30 <adamw> mumblegrumblepeoplewhodon'treadtheagendamumble
16:25:38 <tflink> agenda?
16:25:41 <tflink> :-D
16:25:42 <adamw> =)
16:26:09 <adamw> so final tc1 is currently scheduled for 12-11, two weeks from now
16:26:21 <Martix> when final TC images starts releasing?
16:26:21 <adamw> with go/no-go on 01-01
16:26:32 <adamw> assuming jreznik's space is correct, anyhow
16:26:36 <Martix> adamw: ok
16:26:37 <tflink> new years day? whose bright idea was that?
16:26:51 <adamw> fesco?
16:26:54 <adamw> blame fesco!
16:26:59 <tflink> sounds like a plan to me
16:27:15 <Martix> lol
16:27:31 <Martix> 01-01? certainly No-Go
16:27:40 <tflink> I'd like to get testable images started as soon as we have another anaconda build
16:27:50 <tflink> whether that's in the format of smoke images or TCs
16:27:52 <adamw> so that'd give us three weeks for validation. we could move it up yet further just to make us all even more sick of validation. but it might be better, i guess, to look at that after we do one blocker review meeting at least, and co-ordinate with anaconda team, see what their plans are
16:27:52 <Martix> tflink: +1
16:28:02 <adamw> it might be a solid plan to have smokes all the way, tough
16:28:25 <tflink> on a side note, work is progressing somewhat on the image building project from GSoC
16:28:45 <adamw> #agreed we should build at least smoketest images throughout final phase, from now onwards
16:28:47 <tflink> I don't think it's going to be done before F18 is over with but I'm hoping to start using it for smoke images soon
16:28:53 <adamw> awesome!
16:29:34 <adamw> #info imagebuilder may be usable for Final smoketest images
16:29:50 <tflink> ideally, I'll be able to get something set up to watch for anaconda builds and trigger new smoke images but that's more than likely to be "crazy fantasy land"
16:29:54 <adamw> #action adamw to co-ordinate with anaconda team on TC1 date planning
16:30:56 <adamw> okay, anything else on 18 beta/final before we go on to test case / criteria stuff?
16:31:58 * Viking-Ice scrolls up
16:32:41 * adamw gives viking-ice a minute
16:33:50 <Viking-Ice> let's carry on
16:34:06 <adamw> okey dokey, yell if you think of anything
16:34:16 <adamw> #topic Test case / criteria revision
16:34:25 <adamw> so i just put this in as a kind of catch-all topic
16:34:36 <adamw> i know I still suck and haven't figured out the partitioning criteria, sorry.
16:35:04 <tflink> .fire adamw
16:35:04 <zodbot> adamw fires adamw
16:35:20 <maxamillion> awwww, sadface
16:35:27 <tflink> one question I have is whether we're going to block final if there's no fedup gui
16:35:31 <adamw> I'M FREE!
16:35:39 * adamw dances off into distance, clicking heels
16:35:43 <tflink> wait, that's how it works?
16:36:02 <Viking-Ice> tflink, I would say so yes
16:36:06 <Viking-Ice> no gui no release
16:36:07 <adamw> #info kparal and jskladan have been cleaning up several test cases for final
16:36:15 <adamw> i'm inclined to side with viking-ice on that one
16:36:24 <adamw> though not sure if we want to rope in fesco, or what wwoods' take is
16:36:26 <Viking-Ice> tflink, just feed wwoods more alcohol
16:36:28 <tflink> do we want to refine the upgrade criteria for upgrades so that there is less ambiguity when issues arise
16:36:29 <Viking-Ice> ;)
16:36:46 <tflink> ie, fedup theme, visable progress during upgrade, hot-fixability post-release etc.
16:37:06 <adamw> tflink: i'm not so sure if i'd want to go that route as it's not like we'll be rewriting the gui at every release, but that's just mho
16:37:08 <tflink> er, s/visable progress/easily monitor-able progress/
16:37:39 <tflink> I'm less worried about the gui than I am about plymouth integration and progress monitoring
16:38:11 <adamw> yeah, progress monitoring seems like a big thing to have too.
16:38:19 <Viking-Ice> progress monitoring is a must have
16:38:24 * tflink will propose as a final blocker
16:38:24 <adamw> let's make a wishlist
16:38:41 <tflink> wishlist or a musthave list?
16:38:50 <adamw> #agreed general consensus that we expect a) progress monitoring and b) GUI for fedup to be complete for final release
16:38:56 * adamw handwaves
16:39:00 <Viking-Ice> I dont think it has to show which package is being upgraded thou
16:39:02 <adamw> always leave room to back out later!
16:39:12 <adamw> no, just some sort of 'i'm alive, don't reboot me'.
16:39:22 <Viking-Ice> ack
16:39:24 <adamw> and vague 0-100 of some kind.
16:39:25 <tflink> Viking-Ice: that would be nice but I agree that it's probably not worth blocking for
16:39:32 <adamw> oop, sorry, i didn't propose, but sounds like it's okay.
16:40:18 <tflink> this might be better for open floor, but I've been wondering about signing more of the test images - smoke builds and fedup stuff
16:40:29 <adamw> let's make it open floor yeah
16:40:32 <Viking-Ice> tflink, honestly the whole anaconda showing which package is being installed never made sense to me
16:40:46 <Viking-Ice> if the install fails it fails regardless which package was being installed
16:40:47 <adamw> Viking-Ice: in Beta RC1 it doesn't, actually - at least on live
16:40:50 <adamw> it gives you a percentage
16:41:00 <adamw> which is neat.
16:41:18 <adamw> okay, back on criteria!
16:41:27 <tflink> eh, I like seeing which package is being installed - it's a quick indication if the process hangs but I guess it's personal preference
16:41:42 <tflink> either way, not worried about it :)
16:41:58 <adamw> does anyone want to take an action item to review the final criteria and test cases for particularly obvious revision candidates?
16:42:07 <adamw> or should i just assign it to jskladan in his absence? :)
16:43:08 <tflink> that'll teach him not to show up :-P
16:43:18 * kparal agrees
16:43:31 <adamw> eeeeexcellent
16:43:45 <adamw> #action jskladan to review final criteria and test cases for obvious revision candidates
16:43:50 <adamw> can you let him know, kparal? thanks
16:43:55 <kparal> adamw: sure
16:44:16 <kparal> pschindl: can you remind me that tomorrow?
16:44:49 <kparal> pschindl: don't forget to delegate this process further
16:45:32 <tflink> another action for josef?
16:45:33 <adamw> some chicken farmer in swaziland is going to wake up with a todo item for this tomorrow, isn't he
16:46:00 <tflink> #action jskladan to remind pschindl to remind kparal to let jskladan know that he got an action item
16:46:16 <adamw> i like it!
16:46:26 <pschindl> kparal: I will remind you ;-)
16:46:26 <adamw> rhl: lean, mean, efficiency machine
16:46:54 <tflink> the circle is now complete ...
16:47:19 <adamw> okay, that sounds good
16:47:27 <adamw> anything else before we go on to open floor?
16:47:27 <Martix> ack
16:48:37 <adamw> #topic open floor
16:48:41 <satellit_e> https://bugzilla.redhat.com/show_bug.cgi?id=880300 easy way to format USB with no swap and / partitions (non LVM)
16:48:42 <adamw> fire away with crazy ideas now!
16:49:01 <tflink> I've been wondering about signing more of the test images that we're using
16:49:04 <adamw> satellit: i saw that. to be honest it doesn't make any sense. it's as simple to make non-LVM partitions as any other kind.
16:49:10 <adamw> #topic open floor - image signing
16:49:23 <tflink> I'm just not sure it's worth the effort
16:49:28 <adamw> tflink: this comes under 'desirable but not critical' for me, especially if it'd make the process any heavier
16:49:44 <satellit_e> ok
16:49:48 <adamw> i really would hope that no-one is installing smoketest images and then actually *using* them for anything
16:50:07 <tflink> yeah, that's mostly why I'm wondering if it would be worth any effort
16:50:07 <Viking-Ice> agreed I think signing smokes is useless
16:50:31 <Viking-Ice> smokes are kinda use once discard
16:50:43 <tflink> fedup testing is more arguable, though
16:50:57 <adamw> so i'd say don't waste more than minimal time on it, and especially not worth it if it makes it more complex/time-consuming to build smokes
16:51:03 <adamw> we have a bug for fedup signing, right?
16:51:13 <tflink> yeah, that's as much a releng issue, though
16:51:30 <tflink> if we did do it, I'd wonder what key to use
16:52:00 <tflink> I can sign them myself but that doesn't seem quite right and there's no way I'm putting my gpg key on a regular infra machine
16:52:33 <adamw> another darn thing.
16:52:55 <tflink> I'll keep it in mind but I suspect that there are going to be higher priorities for final
16:53:07 <adamw> so when you say fedup signing, signing what exactly? there are various bits, right? are we talking the upgrade.img here?
16:53:18 <tflink> the upgrade.img, yeah
16:53:21 <adamw> ok
16:53:38 <adamw> well i guess the process i'd expect there is that it gets generated by releng and signed by releng, but i may be in cuckoo land
16:53:41 <tflink> I suppose that if we're not testing stuff only in git, it doesn't matter a whole lot, though
16:54:27 <tflink> I'm tempted to not do it unless there is enough complaining to justify the effort or we need to start testing some sort of verification
16:55:05 <Viking-Ice> do we have any page that outlines the upgrade.img and it's process?
16:55:26 <tflink> building or using?
16:55:45 <tflink> upgrade documentation is on my todo list for today, already have an action item or two
16:56:13 <Viking-Ice> both fedup progress in general how it (supposed to ) work etc
16:56:44 <tflink> I'm planning to update the testing page once I have some basic usage docs in place
16:56:57 <adamw> we already did some planning for documenting the user side of things
16:57:02 <tflink> that's what I've been trying to use to record progress, what to expect etc.
16:57:10 <adamw> that was before you came in
16:57:21 * tflink has another item for open floor once we're done with this
16:57:45 <Viking-Ice> we need documentation on the whole process not just the user side of things
16:58:01 <tflink> Viking-Ice: what do you mean "the whole process"?
16:58:17 <tflink> that's rather vague and I'm not 100% sure what exactly you're getting at
16:58:28 <Viking-Ice> how the upgrade process is supposed to work
16:58:38 <Viking-Ice> from a - z
16:58:45 <tflink> how is that different from user-facing docs?
16:59:11 <Viking-Ice> has to do with making criteria decision for the process
17:00:04 <tflink> I might just be slow this morning but I'm still not following you
17:00:14 <adamw> i think he means almost a design document
17:00:21 <Viking-Ice> until we have those docs we cant adjust any criteria surrounding it
17:00:34 <adamw> here's how the Final Finished Fedup Process is envisioned to work - no temporary locations, no UI hacks
17:00:39 <adamw> right?
17:00:43 <Viking-Ice> since no one in the QA community will have other then vague idea how it works
17:01:08 <tflink> I'm not against the idea but I'm not sure I'm really qualified to write stuff like that
17:01:35 <tflink> since I only have vague, seldom-mentioned-in-irc plans to go off of
17:02:11 <adamw> yeah it seems like it'd be best coming from wwoods
17:02:17 <adamw> i agree it seems like a good thing to have though
17:02:25 <adamw> do you want an action item to try and get one out of wwoods?
17:02:55 <tflink> I can ask him about it, sure
17:03:04 <adamw> i meant viking-ice, but either way
17:03:49 <adamw> Viking-Ice: do you want to take it? or give it to tflink?
17:05:36 <adamw> #action viking-ice or tflink to try and get a fedup design document out of wwoods
17:05:50 <adamw> alrighty
17:05:53 <adamw> #topic open floor
17:05:56 <adamw> anything else for open floor, anyone?
17:06:12 <tflink> yeah, zsync - http://zsync.moria.org.uk/
17:06:30 <tflink> if I figure out how to get that to work for the smoke images, would people use it?
17:06:49 <tflink> there is no fedora package for it due to bundled zlib
17:06:57 <adamw> is that like deltaiso? or what?
17:07:02 <adamw> i use deltaisos all the time
17:07:14 <tflink> a more generic form of deltaiso
17:07:21 <tflink> and probably a bit more efficient
17:07:39 <kparal> tflink: robatino uses that for all TC/RC images
17:07:52 <tflink> yeah, that's who I heard about it from
17:07:53 <kparal> tflink: http://dl.fedoraproject.org/pub/alt/stage/deltaisos/zsync/
17:07:56 <adamw> well count me in favour of anything deltaiso-y
17:08:09 <kparal> zsync is still not acceptable in Fedora
17:08:20 <kparal> but there's a rsync update that unbundles zlib
17:08:23 <tflink> but the documentation isn't 100% clear and I wanted to get an idea of how much it would be used before putting time into it
17:08:27 <kparal> that's a step in the right direction
17:08:38 <tflink> I thought that didn't work with zsync
17:08:45 <robatino> basically rsync except putting the load on the client instead of the server
17:08:45 <adamw> #info tflink looking at zsync for smoketest images
17:08:59 <tflink> but I haven't checked the review bug for zsync in the last week, I could be mis-remembering
17:09:49 <kparal> tflink: basically first we need to push rsync update to Fedora that unbundles zlib, then we have to change zsync to unbundle it as well, and then we can accept zsync info Fedora
17:10:16 <tflink> ok, it sounds like I was thinking of a different patch
17:10:31 * kparal links https://bugzilla.redhat.com/show_bug.cgi?id=495310
17:10:43 <tflink> either way, we could still put zsync packages w/ bundled zlib in a side repo for the short term
17:10:56 <adamw> ok, we've over an hour
17:10:57 <kparal> tflink: opensuse has them, their rpm works great
17:11:11 <tflink> kparal: do you have a link off hand?
17:11:14 <adamw> do we need the technical zsync discussion here, or can we wrap up? any other topics?
17:11:27 <tflink> nothing from me
17:11:44 <kparal> tflink: http://software.opensuse.org/package/zsync?search_term=zsync
17:11:45 <tflink> we can take the zsync details elsewhere, I was mostly wondering about interest
17:12:02 * kparal thinks zsync is great
17:12:25 <adamw> +1
17:12:26 <kparal> tflink: it doesn't work well for Live images, just netinst/DVD
17:12:40 <adamw> ok, setting fuse for Professor X minutes
17:12:40 <tflink> I wonder why that is
17:12:51 <kparal> tflink: you might also want to look at http://kparal.wordpress.com/2009/09/01/zsync-transfer-large-files-efficiently/
17:14:20 <robatino> i thought it was interesting that ubuntu's live downloads work well with rsync/zsync
17:14:53 <kparal> it's 3 years old measurement, things might have changed
17:15:08 <adamw> alright! zsync discussion to -qa please
17:15:13 <adamw> thanks for coming folks
17:15:15 <adamw> #endmeeting