15:02:06 <adamw> #startmeeting Fedora QA meeting
15:02:06 <zodbot> Meeting started Mon Sep 17 15:02:06 2012 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:08 <adamw> #meetingname fedora-qa
15:02:08 <zodbot> The meeting name has been set to 'fedora-qa'
15:02:10 <adamw> #topic roll call
15:02:19 * nirik is lurking
15:02:24 * satellit listening
15:02:45 * mkrizek is here
15:02:50 * tflink is here
15:03:02 * brunowolff is here
15:03:06 <adamw> morning, folks
15:03:25 * pschindl is here
15:03:35 * spoore is lurking
15:04:03 * kparal arrives late
15:04:06 <adamw> ominous!
15:04:14 <adamw> so many lurkers
15:04:18 <adamw> practicing for halloween?
15:04:21 * jskladan tips his hat
15:05:39 * adamw tips his head
15:05:41 <adamw> alrighty
15:06:13 <adamw> #topic Fedora 18 Alpha wind-up / Beta preparation
15:06:39 <adamw> so we somehow decided to ship apha
15:06:41 <adamw> alpha*
15:06:44 <adamw> congrats on that, everyone
15:06:58 <tflink> wheee!
15:07:28 <adamw> ...is the noise of unsuspecting hard disks being wiped
15:07:34 <adamw> :P
15:08:08 <adamw> so obviously, we all know alpha's in fairly rough shape; one thing we clearly need is to have the common bugs page up and ready for tomorrow
15:08:13 <adamw> i'm planning on working on it today, but help is welcome
15:08:38 <adamw> and it'd be great if everyone could ensure that their 'favourite' alpha bug has the CommonBugs keyword, i tried to mark the biggest ones as we went along but i may have missed some
15:08:58 <adamw> #info alpha is done, release tomorrow, we need to get common bugs page up and ready
15:09:50 <adamw> the other thing i had on my alpha list is the release announcement...
15:09:56 <adamw> jskladan: are you in charge of that?
15:11:27 <kparal> I think nirik usually did the announcement?
15:12:27 <adamw> nirik? i don't think so
15:12:35 <adamw> so, let's make that...
15:12:47 <adamw> #action adamw to find out who's writing the release announcement and make sure it calls out the biggest Alpha bugs
15:13:02 <kparal> so dgilmore? http://lists.fedoraproject.org/pipermail/announce/2012-February/003044.html
15:13:06 <nirik> For alpha / beta I think dgilmore does it.
15:13:08 <adamw> ah
15:13:17 <adamw> thanks for that
15:13:30 <adamw> so that's what i had noted down for Alpha prep, anyone think of anything else we should get out in front of?
15:14:03 <kparal> just a question - when is the branched tree going to be unfrozen?
15:14:29 <adamw> i thought it already was, dgilmore said he was going to do a stable push on friday...
15:14:33 <nirik> kparal: it has been already, we just had a bunch of trouble with our signing server over the weekend.
15:14:36 <adamw> ah
15:14:45 <kparal> ok, thanks for info
15:14:55 <nirik> so, hopefully stable push should happen today
15:15:01 <kparal> great
15:15:07 <adamw> #info Alpha is now officially unfrozen, but releng has had trouble with the signing server which is why the stable push hasn't happened yet
15:15:44 * jreznik is listening, is late...
15:16:33 <adamw> btw, for troubleshooting purposes, i believe it's the case that newUI net installs at present will always use updates-testing
15:16:44 <adamw> unless you specify only a 'fedora' repo manually, i guess
15:17:53 <adamw> so if that's all we have for alpha...
15:17:54 <kparal> adamw: correct
15:18:03 <adamw> onto the topic of beta preparation
15:18:24 <adamw> some of this overlaps with the release criteria topic to follow, i guess
15:19:02 <adamw> but aside from that, does anyone have any ideas for trying to make beta go a bit smoother than alpha?
15:20:08 <tflink> freeze entrance requirements?
15:20:23 <nirik> at least having nightly lives might help
15:20:47 <adamw> what's the status of nightly lives?
15:20:54 <adamw> anything missing for us to get them from now on?
15:21:08 <tflink> something to the effect of: all potentially release blocking features must be testable before entering freeze
15:21:44 <adamw> tflink: i was gonna do one at a time :)
15:21:47 <nirik> adamw: should work... I've not done them in a few days since there's been no stable changes. ;)
15:22:23 <brunowolff> There have been some spin-kickstarts changes over the last few days.
15:23:12 <adamw> #info nightly lives should help in Beta preparation, and should be available after the unfreeze is in effect
15:23:57 <adamw> so i like the freeze entry criteria idea tflink, but it might be a bit ambitious to try and spring it on everyone within a release cycle?
15:24:02 <jreznik> +1 to live nightlies
15:24:14 <satellit> +1
15:24:22 <nirik> brunowolff: yeah, but not to f18 branch. ;)
15:25:06 <adamw> satellit: +1 what? :)
15:25:24 <tflink> adamw: a bit ambitious, possibly but I imagine that we would get devel support for something that could/would help decrese the time we're in freeze
15:25:50 <kparal> nirik: nightlies are created from stable updates, right?
15:25:50 <jreznik> tflink, adamw: actually for anaconda, fesco required in ticket status report week before beta change deadline
15:25:50 <satellit> live nightlies
15:26:01 <nirik> kparal: yes
15:26:10 * maxamillion is uber late, but here
15:26:13 <nirik> kparal: well, they do not use updates-testing
15:26:21 <kparal> nirik: thanks
15:26:34 <tflink> jreznik: true, but this isn't just about anaconda and that's just a status report
15:26:50 <satellit> info:livecd-tools spin-kickstart will not build in f18 alpha
15:27:33 <adamw> satellit: i'm planning to test out live composes a bit later and fix any problems I can
15:27:33 <tflink> freeze is not fun for anybody, it'd be nice to decrease the time we spend in freeze by making sure that the release has at least a chance of exiting freeze before we start
15:27:51 <jreznik> tflink: I'd say it's more than status report, it's way how to push on them... and anaconda is top thing with high risk of problems this release... but I'm not against extending it to other top features matchis release criteria
15:28:09 <jreznik> tflink: but yeah, I understand you
15:28:38 <tflink> I don't think that it would hurt to come up with a list of things that we as QA would like to see before entering freeze, though
15:29:26 <adamw> the bait for this hook is 'would you rather slip three weeks while frozen or while not frozen?', presumably
15:29:29 <tflink> spin up a compose a couple of days before the freeze is supposed to start and see how well it's doing
15:29:32 <cmurf> What is a rough time frame on when beta TC's with latest anaconda will appear?
15:29:34 <jreznik> tflink: yep, I'm in and and I can do that annoying task poking people to make sure it's done :)
15:30:07 <tflink> cmurf: I'm planning to do an unofficial spin shortly after release
15:30:09 <jreznik> tflink: nigthlies should work a little bit with this - ala spin up a compose few days before
15:30:33 <tflink> once the massive stable push is done, anyways
15:30:55 <adamw> cmurf: we have a specific date for the official TC1
15:30:56 <tflink> ATM, I'm fighting with livecd-creator for the i18n test day lives, though
15:31:15 <adamw> #info official Beta TC1 release date is 2012-10-02
15:31:28 <tflink> adamw: I think he was asking when something to test the latest anaconda was going to be available for testing instead of an actual TC
15:31:30 <adamw> we could of course start doing TCs earlier, but the danger of that is test fatigue
15:32:04 <adamw> we'll definitely look at doing smoketest images more frequently
15:32:14 <tflink> I don't think that we need to start doing regular TCs too early but I also think that it would be good to have a handle on what is and isn't working right earlier
15:32:14 <maxamillion> adamw: combination of fatigue and folks just ignoring the earlier runs of TCs
15:32:29 <adamw> right
15:33:03 <adamw> #agreed doing official TCs earlier would probably be overkill, but we will aim to do frequent smoketest images
15:33:56 <adamw> #info tflink proposes having freeze entrance criteria - requirements that must be met before we start the freeze for a release point
15:34:34 <adamw> so if we were to go ahead with that idea, tflink, what would your plan be?
15:34:50 <tflink> which idea? the freeze entrance requirements?
15:34:54 <adamw> draft up a proper wording of the idea on test@ then try and sell it to the rest oft he project?
15:34:55 <adamw> yeah
15:35:05 * jreznik likes the idea of freeze entrance criteria - but how do we proceed in case we do not meet the criteria?
15:35:18 <tflink> it would require buy-in from others, I think
15:35:37 <tflink> but drafting up the requirements on test@ would be a good place to start
15:35:58 <tflink> the idea would be to slip just like we would in freeze - if the requirements aren't met by X date, we slip a week
15:36:15 <tflink> the exact requirements might be a bit of a challenge, though
15:36:20 <brunowolff> Would there be a partial freeze during this time? (Say for crit path type stuff.)
15:36:26 <tflink> it's hard to quantify worky-ness
15:36:31 <adamw> that seems like overcomplicated things
15:36:35 <adamw> (the pre-freeze thing)
15:36:51 <tflink> the idea is to decrease the time we spend in freeze, I think
15:37:07 <tflink> without adding too much process and complication
15:37:08 <cmurf> the first beta TC is 10/2
15:37:10 * kparal would also prefer having shorter freeze
15:37:50 <tflink> if the freeze requirements proposal on test@ goes over well, I imagine that it would eventually have to be proposed to fesco
15:37:54 <adamw> cmurf: yeah, i #info'ed that above
15:38:16 <brunowolff> I think the long freeze here was an exception and and a new way to limit freeze time might be more trouble than it's worth.
15:38:20 <adamw> so, the drafting part of the process may as well happen ASAP
15:38:47 <adamw> brunowolff: that is a concern - are we reacting to specific transient circumstances not structural concerns?
15:39:06 <tflink> this wasn't the first 4+ week freeze, though
15:39:25 <adamw> #action tflink to draft up a freeze entrance requirements proposal for the list and we can take the idea from there
15:39:29 <adamw> ok if we move on? time's a tickin'
15:39:31 <tflink> whether freeze entrance requirements would have helped in any of those cases is a different question, though
15:39:34 <tflink> sure
15:39:54 <adamw> tflink: that would be a good thing for you to look at, since virtually everything to do with release validation is documented
15:40:05 <adamw> should be easy enough to look back on the points where we had long freezes, and see if this idea would have helped
15:40:30 <tflink> adamw: I think that it would help our case if we can show that it would have helped decrease freeze length in other cases
15:40:34 <adamw> yup
15:40:41 <tflink> or at least have ideas on how long freezes usually are
15:40:41 <adamw> #topic release criteria revision
15:41:31 <adamw> so i really should have figured out exactly what proposals are active before the meeting
15:41:32 <adamw> silly me
15:42:42 <pschindl> default package set, lvm and raid
15:42:55 <adamw> also mediacheck (from andre last month)
15:43:14 <adamw> also chuck's idea which was pretty much universally shot down, so we can ignore that one...
15:43:55 <pschindl> and the one with 'uncategorized package groups'
15:44:10 <adamw> right
15:44:52 <adamw> i think dropping uncategorized package groups criterion should be fine
15:44:55 <adamw> did you do that yet?
15:46:00 <pschindl> no, I waited on some comments
15:46:18 <pschindl> I'll do it if there are no objections
15:46:54 * kparal agrees
15:47:09 <tflink> I forget, has the discussion around the different install types started (use all space, use free space etc.)?
15:47:16 <adamw> anyone object to dropping the requirement for 'no uncategorized package groups', on the basis it doesn't apply to newui?
15:47:23 <adamw> tflink: no, that's one we need to do
15:47:34 * kparal notes the test@ topic is: "[criteria update] Update of uncategorized package groups criterion"
15:47:34 <adamw> tflink: it'll help to see how the final newui design is actually supposed to work
15:47:40 <adamw> tflink: i was trying to work through one thing at a time though :)
15:48:01 <tflink> ok, I just figured that the sooner we get that figured out, the better
15:48:08 <adamw> sorry, my bad for not structuring the topic well enough
15:48:13 <tflink> no objections to dropping that requirement
15:48:21 <tflink> none from me, anyways
15:48:25 <adamw> pschindl: sounds like you can go ahead and kill it
15:48:40 <pschindl> with fire
15:48:59 <cmurf> final newui is what i'm most interested in, and feel that beta TC1 is already at the point where mostly triage will need to occur
15:49:28 <adamw> ok, so on the package set criterion
15:49:53 <adamw> looks like the latest actual proposal we have is kparal's "'The installer must be able to (successfully) install *all release-blocking desktops* for each supported installation method (DVD, live, netinst, PXE, ...)'"
15:50:10 <adamw> that seemed to be going in the right direction to me, without the punctuation :)
15:50:18 <adamw> but i'd like to add minimal to the list
15:50:25 <pschindl> +1 for minimal
15:50:39 <adamw> any other thoughts on that criterion?
15:50:48 <adamw> this is the one to replace the 'default package set' criterion, since there is no default any more
15:50:51 <tflink> +1 for minimal
15:50:58 <kparal> also +1 for minimal
15:51:40 <jreznik> does all rel-blocking desktops means all together at once (not supported) or just install one at time, but all should be installable :) could be confusing
15:51:52 <tflink> one at a time, I think
15:52:00 <tflink> since multiple can't be selected @ install time
15:52:00 <brunowolff> I believe one at a time.
15:52:04 <kparal> I don't find that confusing
15:52:13 <tflink> s/all/any
15:52:15 <tflink> ?
15:52:22 <adamw> we could say 'each of the release blocking desktops' if we felt it needed clarifying
15:52:30 <jreznik> adamw: +1
15:52:42 <tflink> 'any single release-blocking desktop package set'?
15:53:00 <tflink> 'any single release-blocking desktop base package set'?
15:53:19 <kparal> tflink: too complicated?
15:53:19 <adamw> that's starting to sound like how i write them =)
15:53:25 <tflink> I assume that we don't want to get into additional package selection with that requirement
15:53:29 * adamw missed his calling as a lawyer
15:53:47 <kparal> 'each of the release blocking desktops' is fine
15:53:59 <jsmith> adamw: Say it isn't so...
15:54:11 <adamw> ok
15:54:16 <kparal> my idea is that it should be understandable also for non-members of the QA team
15:54:27 <kparal> because we ask people to tag release blockers
15:54:27 <adamw> so sounds like we're broadly happy with the direction of that criterion at least
15:54:45 <adamw> yeah, ideally they should, i'm all in favour of trying to keep the language simple, i'm just not very good at it =)
15:54:57 <tflink> yeah, I'm fine with keeping it simple as long as we don't fall in to too many long discussions during blocker meetings :)
15:55:22 <tflink> shorter requirements are easier to use during the meetings and on bugzilla, anyways
15:55:54 <adamw> i think we might not  be able to say much useful about partitioning at this meeting, since we kinda need to see the beta newUI design
15:56:08 <kparal> we can have short requirements and append a detailed explanation below it
15:56:35 <tflink> kparal: doesn't that have the potential to be just as complex and confusing?
15:56:49 <tflink> but probably less confusing and complex than the current situation
15:56:49 <adamw> right
15:56:56 <adamw> i've thought about something like that before
15:57:06 <tflink> how would we structure the wiki page?
15:57:11 <adamw> didn't get that far
15:57:28 <adamw> but we often wind up talking about the intent of a criterion, or the way it was drawn up, or whatever, and it'd probably be good to have that information 'canonized'
15:57:32 <tflink> maybe use sections for the requirements instead of a numbered list?
15:57:46 <tflink> have the short version be the section title and the explanation follow?
15:57:57 <kparal> I'd like to have self-collapsible elements in the wiki. the detailed description would be hidden and would unwind after click
15:57:59 <adamw> #agreed 'uncategorized package groups' criterion can be dropped
15:58:20 <adamw> #agreed group is happy with the direction of kparal's proposal on the 'default package set' replacement criterion, further work to happen on-list
15:58:27 <tflink> or we could have a wiki page per requirement
15:58:28 <adamw> kparal: ooh, that'd be shiny
15:58:37 <adamw> tflink: god no, they'd all wind up 2000 words long
15:58:41 <adamw> and it'd probably be my fault :P
15:58:47 <kparal> tflink: I would also like to have all requirements on a single page, because of searching
15:58:57 <kparal> I mean Alpha + Beta + Final
15:59:19 <tflink> yeah, that would be nice but we'd have to figure out how to represent the information correctly
15:59:43 <tflink> it has the potential to become such a huge wall of text that it's not easily understandable
15:59:51 <adamw> yeah, that's what we need to avoid
16:00:09 <adamw> so on partitioning...it seems like people generally liked the idea of minimal requirements at alpha time
16:00:55 <adamw> my proposal was "The installer must be able to complete an installation using automatic partitioning to any sufficiently large target disk, whether unformatted, empty, or containing any kind of existing data".
16:01:05 <adamw> and we seemed to more or less go with that for alpha
16:01:35 <adamw> does anyone worry that it's too minimal?
16:02:22 <pschindl> I would add 'or to existing free space'
16:02:23 <tflink> so do we add encryption and/or LVM @ beta?
16:02:55 <adamw> pschindl: alpha would still not be out, in that case ;)
16:03:05 <pschindl> I'm +1 for LVM and encryption in beta.
16:03:07 <adamw> tflink: i'd like to see the beta design...
16:03:12 <kparal> pschindl: automated partitioning means you don't really know what it does, you just assume it will eat the whole disk
16:03:15 <kparal> that's how I read it
16:03:27 <adamw> kparal: that's implicit as it stands, yes. f18 alpha passes that criterion.
16:03:35 <tflink> I'm ok with just that for alpha
16:03:46 <tflink> but I'm not so sure about no encryption or LVM for beta
16:03:47 <pschindl> adamw: I know :) and I would slip again.
16:04:04 <adamw> ok, so obviously we need to poke that one some more
16:04:11 <adamw> sorry if i'm hustling here but we're over 1hr already
16:04:15 * kparal is ok with that Alpha criterion
16:04:23 * pschindl too
16:04:37 <pschindl> let it be as simple, as it could
16:05:08 <pschindl> but anaconda should be prepared for hell in beta stage
16:05:44 <adamw> #info group mostly happy with minimal criterion for partitioning at alpha stage, though a question over whether install to existing free space should be possible
16:06:00 <adamw> it sounds like there's a general opinion that beta requirements should be significantly tighter than alpha
16:06:32 <tflink> yeah, beta == general testing for final
16:06:56 <tflink> I think it's very unwise to suddenly add tons of requirements for final that did not exist for beta
16:07:00 <adamw> #info general agreement that beta partitioning requirements should be significantly stricter than alpha
16:07:22 <tflink> expecially base stuff that is expected to work @ release like installing an encrypted system
16:07:33 <adamw> #info hard to decide on beta/final partitioning requirements until we see the planned changes to newUI partitioning workflow
16:08:52 <adamw> #action pschindl to kill 'uncategorized package groups' criterion
16:09:02 <pschindl> adamw: done
16:09:09 <adamw> #action kparal to refine 'release-blocking package sets' criterion
16:09:17 <adamw> #action adamw to refine alpha partitioning criterion
16:09:26 * adamw just stockpiling things to check up on next week =)
16:09:39 <kparal> adamw: have we decided on that criterion already?
16:09:46 <adamw> kparal: which one?
16:09:47 <rbergeron> LOL
16:10:00 <tflink> at some point, I think we'll want to start the conversation about how we're communicating release requirements
16:10:08 <kparal> adamw: my action
16:10:18 <kparal> 'each of the release blocking desktops' is the final version then?
16:10:20 <tflink> not sure if it's a good idea to drastically change stuff for F18, though
16:10:54 <kparal> adamw: or should I just revive the email thread?
16:10:59 <adamw> kparal: nah, sorry, i meant take the feedback from the meeting and update the thread proposal...yup
16:11:06 <kparal> adamw: ok
16:11:21 <adamw> we'll probably revisit this next week
16:11:59 <adamw> ok, so we're running over time so i'll keep this brief, but as a more general criteria topic, for alpha we wound up bending quite a long way on the criteria we had in place, which isn't ideal
16:12:14 <adamw> i'd be much happier with a situation where we can stick firmly to the criteria we have
16:12:37 <adamw> so it'd be nice for beta to ensure by the time we hit TC1, the beta criteria in place are ones we're confident in standing solidly by
16:13:00 <adamw> i think it's better to weaken a criterion than just fudge it or waive it in a review meeting...
16:13:20 <tflink> I'd add to that by suggesting that we don't waive blockers in the review meetings
16:13:34 <tflink> if blockers get waived, wait for go/no-go at least
16:13:42 <adamw> so after we get through these specific proposals, we should look through the list as a whole and make sure it's all updated for newUI and all as tight as it can be
16:14:07 <adamw> tflink: i think that's what we have done, i don't think we've waived criteria in blocker review meetings. we've agreed to *amend* the criteria, but that's all
16:14:40 <adamw> but i agree that's definitely the right way of doing things and we should keep it that way
16:16:19 <adamw> #info tflink reminds that we should never waive criteria in blocker review meetings, if it's going to happen, it should happen at go/no-go
16:16:28 <adamw> ok...anything else on criteria?
16:17:36 <adamw> alrighty
16:17:45 <adamw> so we have the TC/RC naming debate on the agenda, but this has gone pretty long
16:17:50 <adamw> do we want to do that now or table it?
16:18:13 <kparal> there was some email thread in the past IIRC?
16:18:21 <kparal> maybe we can revive it?
16:18:34 <adamw> there've been several :)
16:18:41 <adamw> i was hoping a meeting topic would give it a kick in the pants
16:19:27 * adamw is not sensing wild enthusiasm for more meeting
16:20:19 <jreznik> :)
16:20:20 <adamw> #info TC/RC naming topic tabled due to lack of time
16:20:23 <adamw> #topic open floor
16:20:29 <adamw> you have ten seconds :)
16:20:44 <kparal> over
16:21:14 * adamw sets very short fuse and runs like hell
16:21:30 * jreznik is calling police
16:21:32 <adamw> thanks for coming, everyone, looks like we know roughly where we're aiming for beta at least
16:22:23 <adamw> #endmeeting