QA/Meetings/20120917

From FedoraProject

Jump to: navigation, search

Contents

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!