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