QA/Meetings/20120917

Attendees

• adamw (142)
• tflink (60)
• kparal (33)
• pschindl (14)
• jreznik (12)
• nirik (9)
• brunowolff (5)
• satellit (4)
• cmurf (3)
• zodbot (3)
• maxamillion (2)
• spoore (1)
• mkrizek (1)
• rbergeron (1)
• jskladan (1)
• jsmith (1)

Agenda

• Fedora 18 Alpha wind-up / Beta preparation
• Release criteria revision
• Naming of TCs/RCs
• Open floor

Fedora 18 Alpha wind-up / Beta preparation

• We needed to write up the common bugs page and lobby for inclusion of major issues in the release announcement
• Post-Alpha stable updates push had not yet happened due to issues with the signing server
• Nightly images should start showing up after the first stable push
• We agreed to build smoketest images frequently before the first TC date
• tflink proposed having freeze entrance criteria that must be satisfied before the freeze starts, to avoid overlong freeze periods

Release criteria revision

• We agreed to drop the 'uncategorized package groups' criterion
• We agreed kparal was going in the right direction on the 'default package set' criterion revision, further refinement to occur on-list
• We were broadly happy with the very minimal partitioning requirements used for F18 Alpha, though we may wish to require installation into free space to work in future
• We agreed in general that Beta and Final partitioning requirements should be much tighter, but it was hard to decide on specifics without seeing more details of the planned newUI design

Naming of TCs/RCs

• Topic tabled due to time taken by previous topics

Open floor

N/A

Action items

• adamw to find out who's writing the release announcement and make sure it calls out the biggest Alpha bugs
• tflink to draft up a freeze entrance requirements proposal for the list and we can take the idea from there
• pschindl to kill 'uncategorized package groups' criterion
• kparal to refine 'release-blocking package sets' criterion
• adamw to refine alpha partitioning criterion

IRC Log

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

Generated by irclog2html.py 2.10.0 by Marius Gedminas - find it at mg.pov.lt!