QA/Meetings/20121001

Attendees

• adamw (203)
• tflink (76)
• Viking-Ice (58)
• dlehman (23)
• nirik (22)
• kparal (22)
• wwoods (13)
• akshayvyas (8)
• zodbot (4)
• jskladan (2)
• jreznik (2)
• Martix (1)
• mkrizek (1)
• jwb (1)
• pschindl (1)
• viking-ice (0)

Agenda

• Previous meeting follow-up
• Release criteria
• Fedora 18 Beta status / mini blocker review
• Open floor

Previous meeting follow-up

• adamw to refine alpha partitioning criterion - this was done and would be discussed later in the meeting
• adamw to draft new partitioning criterion for Beta once we know what will be in anaconda - this was done and would be discussed later in the meeting
• adamw to consider revisions to 'kickstart delivery method' criterion - not yet done
• tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down - not yet done, tim was waiting for the criteria proposals before sending it out

Release criteria

Partitioning

• Pre-meeting proposals were on the mailing list
• The proposed Alpha criteria were approved without modification
• The proposed Beta criteria were approved with minor modifications to make the intent clearer and add a requirement that custom partitioning be able to destroy partitions
• Possible further criteria were discussed, including one covering the re-use of an existing /home partition, but it was agreed to propose this on the mailing list for further revision

Upgrade

• Pre-meeting proposals were on the mailing list
• The proposed criteria were approved, but with the agreement that the use of the word 'or' is ambiguous and should be improved to clarify the meaning
• To avoid confusion it was agreed that the intent of the criteria is that all three cases for upgrading - minimal package set, GNOME package set, and KDE package set - must work, not any one of the three

Fedora 18 Beta status / mini blocker review

Freeze readiness

• FESCo will be determining this week if the F18 codebase, especially anaconda, is complete enough to enter freeze for Beta, which was planned for 2012-10-09
• The code for the new upgrade tool was available, but it has not had any official release and we did not believe it was yet in a testable state
• The partitioning code in the latest available anaconda release at time of meeting did not yet support non-destructive automatic partitioning into free space
• wwoods affirmed that the new upgrade tool would be testable by the freeze deadline
• dlehman affirmed that the partitioning code would meet the Beta requirements by the freeze deadline
• We agreed that the state of Fedora 18 as of time of meeting was not good enough to freeze for Beta, but if the upgrade tool was testable and the partitioning code met the Beta requirements by the freeze date, then freezing would be acceptable
• We agreed to pass this evaluation on to the FESCo ticket

Mini blocker review

• This was skipped as the meeting had already taken nearly two hours

Open floor

N/A

Action items

• adamw to propose a criterion covering basic (not advanced) re-use of /home for Beta

IRC Log

adamw	#startmeeting Fedora QA Meeting	15:01
zodbot	Meeting started Mon Oct 1 15:01:22 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.	15:01
zodbot	Useful Commands: #action #agreed #halp #info #idea #link #topic.	15:01
adamw	#meetingname fedora-qa	15:01
zodbot	The meeting name has been set to 'fedora-qa'	15:01
adamw	#topic roll call	15:01
adamw	morning folks! who's around for the qa meeting?	15:01
* pschindl is here		15:01
* mkrizek is here		15:01
* jskladan yay for meeting time (before party time)		15:01
* tflink is here		15:01
* nirik is lurking, ping if I can help with anything.		15:01
* kparal hails to the king		15:01
* akshayvyas is here		15:01
* Viking-Ice here		15:02
adamw	#agreed all qa work to be done by nirik	15:02
adamw	nirik: ping ^^^^	15:02
kparal	ack	15:02
Viking-Ice	ack	15:02
tflink	ack	15:02
adamw	:P	15:02
nirik	:)	15:02
nirik	I'll get right on it.	15:02
jskladan	patch: all work to be done by nirik	15:02
kparal	let's be realistic	15:02
kparal	all qa work is enough for one man	15:03
Viking-Ice	only dwalsh can pull that off	15:03
akshayvyas	and that man is ??	15:03
adamw	james bond?	15:03
akshayvyas	:)	15:03
adamw	okey dokey	15:05
tflink	bond is good at breaking stuff, I suppose but I think I'd rather have Q working on that :)	15:05
adamw	#topic Previous meeting follow-up	15:05
adamw	#info "adamw to refine alpha partitioning criterion" and "adamw to draft new partitioning criterion for Beta once we know what will be in anaconda" - the proposal's on the list, we'll come to it later	15:06
adamw	#info "adamw to consider revisions to 'kickstart delivery method' criterion" - didn't get to that one yet, sorry	15:06
adamw	tflink: "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - anything from that?	15:06
* jreznik is here, sorry for being a little bit late		15:07
tflink	nothing yet, no. I was waiting for the partitioning criteria	15:07
tflink	I have a draft email that I'm planning to send out later today	15:07
* jwb is here for kernel stuffs		15:08
adamw	#info "tflink to ask other interested parties (anaconda team, fesco...) to look over the beta criteria and see if there's anything they feel should be dialled down" - tflink was waiting for the revised partitioning criteria before doing this, so will happen soon	15:08
adamw	hi jwb	15:08
Viking-Ice	I think we are missing one or more hd criteria for the storage spoke but other then that I just think we should be more or less on par what other OS are doing	15:09
adamw	just a sec, let me topic up	15:09
adamw	#topic Release criteria: partitioning criteria proposal	15:10
adamw	so, for anyone who missed it, I posted a rough proposal for partitioning criteria to the list last night: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html	15:10
adamw	#info adamw proposed revised partition criteria for F18+ to the list: https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html	15:10
adamw	discuss away!	15:10
adamw	Viking-Ice: 'one or more hd criteria for the storage spoke' - what do you mean exactly?	15:11
tflink	do we care about reuse of encrypted partitions?	15:11
tflink	ie reusing LUKS setup if /home is encrypted	15:11
kparal	ugh, I didn't get to that discussion today	15:11
* kparal reading it		15:11
adamw	tflink: I think yeah we should cover that 'upgrade' scenario	15:13
Viking-Ice	adamw, if you have one or more hd detected and install on to	15:13
kparal	that means fully custom partitioning should be just in Final, right?	15:13
adamw	i did miss that one out	15:13
Viking-Ice	mena too	15:13
Viking-Ice	mean mean frack!	15:13
kparal	I have one concern about that - it wouldn't be tested as well (as if we required it in Beta)	15:13
adamw	dlehman: the (rough) criteria proposal for partitioning is at https://lists.fedoraproject.org/pipermail/test/2012-October/110494.html , if you didn't catch it yet	15:14
tflink	true but I think that reusing LUKS setup falls pretty well into the realm of custom partitioning	15:14
adamw	kparal: the beta criteria i proposed require some specific abilities for the custom part code	15:14
adamw	the second criterion is all stuff you can only do in custom part, in newUI	15:14
kparal	adamw: oh, I have skipped one paragraph. now I see it	15:14
Viking-Ice	for those that have not read it yet http://blog.linuxgrrl.com/2012/09/25/anaconda-bootloader-reusing-home-assigning-partitions-to-disks/	15:15
adamw	and i'd agree with tflink that we should add 're-use existing /home' to that	15:15
Viking-Ice	yeah re-use should be added to the criteria as well	15:15
dlehman	existing LUKS is absolutely custom. always has been.	15:15
adamw	dlehman: that's fine	15:16
tflink	yeah, it kind of branched into two discussions - reusing existing home and reusing existing encrypted home	15:16
adamw	tflink: re-use existing /home is also custom partitioning.	15:16
Viking-Ice	I added a comment there on the blog post what probably is the expected expectation in that regard	15:16
adamw	well, now i think about it	15:17
Viking-Ice	which criteria could be built upon	15:17
tflink	adamw: yeah, but I thought that we were talking about adding that particular use case to what is needed for beta	15:17
adamw	if you have to use custom partitioning for something, then effectively, pre-f18, it was only required at final	15:17
adamw	yeah	15:17
adamw	so if we add anything that required custom partitioning in oldUI to the beta criteria, we're setting the bar higher than previously	15:17
tflink	adamw: good point, final is fine	15:18
Viking-Ice	I tend to agree with kparal that custom partitioning fits in beta criteria ( alpha not required, beta required to work )	15:18
adamw	so we might want to re-word the final criterion a bit to be less vague, rather than adding to beta	15:18
adamw	Viking-Ice: well i was going for a middle way, in which custom partitioning is required to not be hideously broken at beta, but not required to work entirely	15:19
* tflink smells another epicly long release criterion :)		15:19
adamw	heh :)	15:19
Viking-Ice	custom partitioning in anaconda has never work entirely at least not up to the extend kernel supports so I'm not following what you are getting at there?	15:20
* kparal is fine with almost-but-not-fully covered custom partitioning in Beta		15:20
adamw	Viking-Ice: well 'completely' would be 'passes the Final criterion'	15:20
Viking-Ice	just create what 15 partitions on a single drive and see how anaconda handles that ( insane but you know supported by the kernel )	15:21
adamw	oh, here's a modification...	15:21
adamw	change "Creating and assigning" to "Creating, destroying and assigning"	15:21
adamw	or 'removing', whatever	15:21
adamw	i'm looking at making sure the pre-18 *alpha* requirements are covered	15:22
akshayvyas	adamw: +1	15:22
adamw	one of which was the 'existing Linux partition' autopart method, which wiped existing linux installs but left windows alone	15:22
adamw	Viking-Ice: well that's not really anything new, since we're not proposing to change the final criterion...can we focus on the beta?	15:23
adamw	Viking-Ice: is it that you want further requirements for custom part at beta beyond what's already proposed?	15:23
dlehman	does anaconda actually fail when disks contain the maximum number of partitions? if so, it's just because that never happens in real life (or in bugzilla AFAICT)	15:23
Viking-Ice	in alpha only the autopart should be required to work and quite frankly I dont think we should be having multiboot support in our criteria et all unless the other OS support that as well	15:24
adamw	Viking-Ice: well that's what the currently proposed alpha criterion does, so no problem there	15:25
adamw	and we only have multiboot in final, and we're not talking about final right now...	15:25
dlehman	adamw: autopart-in-freespace. I'm not sure how binding this is. Do we need to specify things like "assuming the disk contains a valid disklabel and is bootable, &c" ?	15:25
adamw	dlehman: eh, we don't _need_ to really, we can always clarify that at blocker review time, but maybe we could	15:25
adamw	let me see how verbose it looks	15:26
adamw	dlehman: actually, i think the current wording works fine	15:26
dlehman	you guys have been good in the past at calling out dealbreaker variations so I'm willing to trust you based on that	15:26
Viking-Ice	adamw, are we just talking about fixing the criteria for beta or fixing the criteria in general?	15:27
adamw	Viking-Ice: well right now i'd like to focus on the specific partitioning criteria proposal on the list	15:27
adamw	Viking-Ice: there's a topic later for 'general criteria revision ideas'	15:27
dlehman	adamw: in that free space case, are we supposed to not install any bootloader?	15:27
dlehman	no, I don't know what we used to do	15:28
adamw	dlehman: yeah, i was just pondering that when i went quiet there	15:28
adamw	dlehman: we used to install a bootloader, i would expect we still will. so the wording might need a bit of a change.	15:28
adamw	although, strictly, the MBR isn't part of the 'existing partition table' or 'existing data', really. 'existing user data'?	15:28
dlehman	maybe add something about offering to access preexisting encrypted devices?	15:28
adamw	help? :)	15:29
dlehman	(in custom)	15:29
dlehman	existing partitions or filesystems?	15:29
adamw	dlehman: well, access is needed only for re-use, right>?	15:29
Martix	hi	15:29
dlehman	right	15:29
adamw	the one case we're specifically concerned about there is re-using an existing /home	15:29
adamw	but then we also considered that, per the pre-f18 criteria, that wasn't actually required to work until final	15:29
adamw	so if we add that to beta, we're _tightening_ the requirements	15:30
adamw	i mean we can do that, but it's a consideration	15:30
dlehman	I see	15:30
adamw	it's a bit tricky trying to strike a balance of exactly what we think really needs to be working in custom part by beta, given that custom part is obviously more important in newui since autopart is more restricted.	15:30
adamw	Viking-Ice: so do you have anything you'd like to add to/remove from the beta criteria proposed?	15:31
adamw	dlehman: for the 'empty space' one..."The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"?	15:33
Viking-Ice	adamw, I actually would like to move the whole custom partitioning from final to beta	15:33
dlehman	adamw: sounds okay to me	15:33
tflink	adamw: what about /boot partitions?	15:34
adamw	tflink: in relation to what?	15:34
dlehman	Viking-Ice: if you're going to do that you'll have to do so at the beginning of a cycle	15:34
adamw	if you mean the criterion me and dlehman are discussing, irrelevant, 'autopart into empty space' does not re-use any existing partitions, it'd create its own /boot	15:34
Viking-Ice	dlehman, yup	15:34
tflink	'leaving the pre-existing partitions and data untouched' - does that apply to any existing /boot partitions	15:34
adamw	tflink: per the above, yeah.	15:34
adamw	an install re-using an existing /boot would have to be done through custom part.	15:35
Viking-Ice	dlehman, so it would not be subjected for F18 but F19 if we change it	15:35
adamw	Viking-Ice: ok, so if you're not proposing that for f18, can we table it for now? since it's important that we nail down the f18 requirements	15:35
Viking-Ice	adamw, ok	15:35
adamw	the reason i want to get this done now, btw, is that it feeds into the 'should we freeze beta' discussion	15:35
adamw	whatever we decide the beta criteria need to be, that's what needs to be basically implemented before we freeze for beta	15:36
adamw	ditto for upgrade	15:36
adamw	so here's what we have so far, modified from the list proposal:	15:36
adamw	1. "The installer must be able to complete an installation using automatic partitioning to a validly-formatted disk with sufficient empty space, using the empty space and installing a bootloader but leaving the pre-existing partitions and data untouched"	15:37
adamw	2. "The installer's custom partitioning mode must be capable of the following:"	15:37
adamw	2a. "Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types"	15:37
adamw	2b. "Creating encrypted partitions"	15:37
adamw	2c. "Rejecting obviously invalid operations without crashing"	15:37
adamw	any specific proposed revisions to those, to be enforced for f18 beta?	15:37
adamw	does anyone reckon we should include a requirement for re-using an existing /home at beta rather than final?	15:38
tflink	we're leaving LVM for ginal?	15:38
tflink	final	15:38
adamw	tflink: i left LVM on the basis that anaconda team say it's really going to be de-emphasized for newui.	15:38
adamw	LVM is The Past, btr is The Future.	15:38
adamw	but we could change that if we think it's still important enough	15:38
adamw	dlehman: wdyt?	15:38
adamw	tflink: LVM was kinda in the previous criteria because it was the Fedora default and we were very big on it for a while.	15:39
tflink	it's somewhat of a departure from previous requirements but yeah, btr seems like it will replace LVM at some point	15:39
nirik	lvm still needed for encrypted tho right?	15:39
adamw	if fedora isn't so 'ra ra LVM' as it was, which kinda seems to be the case, it's probably not as important	15:39
tflink	adamw: I'd say that reuse of /home is OK for final	15:39
adamw	nirik: no? you can encrypt a regular partition.	15:39
dlehman	nirik: no	15:39
Viking-Ice	"re-use" and "upgrade" criteria belong in the same milestone ( beta from my pov )	15:40
tflink	encryption + LVM == pain (from my experience)	15:40
nirik	ok, cool. I thought it was tied to lvm at one point.	15:40
tflink	well, encrypting the VG == pain, anyways	15:40
akshayvyas	so btrfs is default now	15:40
adamw	akshaysth: not right now no, still ext4	15:41
tflink	for F18? I thought that was still pending	15:41
adamw	but i think the plan is for btrfs as default in future	15:41
Viking-Ice	F20+	15:41
dlehman	adamw: explicit inclusion of lvm in addition to plain partitions?	15:41
adamw	Viking-Ice: i can see that, yeah, since the main use case for re-use is basically upgrading.	15:42
Viking-Ice	yup	15:42
adamw	dlehman: well that's what we were just discussing - i left it out on the basis that you folks thought LVM isn't as important as it used to be, i remember us talking about that in #anaconda, but we can certainly add it back if you think we still should for now.	15:42
akshayvyas	adamw: pointed the wrong one :)	15:42
akshayvyas	akshaysth is someone else	15:43
adamw	Viking-Ice: the counter-point to that is that we require upgrade to be in place for beta because upgrade is complex and so we want it in beta so people can test it and report bugs and they can get fixed for final	15:43
adamw	Viking-Ice: re-use of /home isn't at all as complex an operation as an upgrade installation is	15:43
adamw	it doesn't really need months of testing, it just...either works or doesn't work	15:43
tflink	adamw: reuse of non-encrypted home, sure	15:44
adamw	true, encrypted home is a bit messier	15:44
Viking-Ice	depends on how you look at it, that feature from my pov of view should be handled automatically from the storage spoke ( as opposed forcing the user having to go to custom partitioning and do all the necessary steps there )	15:44
adamw	anyhow, we're now debating *strengthening* the proposed criteria, i don't hear anyone saying we should weaken them	15:44
adamw	so should we approve what's proposed now as a baseline at least? we can always tighten things from there	15:44
dlehman	adamw: I don't really know, to be honest. partitions are a must. lvm, md, btrfs, all debatable.	15:44
* tflink wonders about leaving md and btrfs for final, though		15:45
adamw	Viking-Ice: i don't think that's gonna happen for 18 at least, aiui. re-use is something you'll definitely have to do through custom part (like it was in oldui)	15:45
tflink	seems like it could cause a lot of problems, no matter when it lands, I suppose	15:45
adamw	tflink: we don't have them in the current beta proposal, dlehman was floating them,	15:45
dlehman	Viking-Ice: that amounts to a sizable RFE, so not going to add that for F18.	15:45
tflink	I'm not against the idea of requiring md and btrfs/lvm for beta as long as we're being reasonable	15:46
adamw	ok, so how bout this: we vote on approving the new criteria proposed above, then i'll send out a new mail proposing some kind of limited re-use of /home requirement for beta, to be discussed separately	15:47
Viking-Ice	adamw, then it falls just under the general custom partitioning criteria	15:47
adamw	Viking-Ice: it'd certainly be covered by the existing final criterion yes	15:47
tflink	adamw: works for me	15:47
adamw	Viking-Ice: but we could also add it to beta if we want it to work by beta	15:47
Viking-Ice	ack	15:47
Viking-Ice	to the limited beta criteria proposal surrounding re-use of /home	15:47
* tflink is +1 on the partitioning criteria as proposed above		15:47
dlehman	adamw: the biggest problems with btrfs and lvm are they are so overfull with options that requiring support for any existing config is quite a demand. creating what is supported in the installer, OTOH, it not.	15:48
adamw	propose #agreed the modified proposed criteria given at XX:37 in the log are approved as the baseline requirements for F18 beta, further requirements have been suggested but will be discussed separately	15:48
Viking-Ice	dlack	15:48
tflink	ack	15:49
Viking-Ice	mean ack	15:49
akshayvyas	ack	15:49
adamw	dlehman: right, hence the proposal for a 'limited' re-use criterion - i was thinking exactly along the lines of *not* needing any kind of massively complex encrypted-btrfs-on-encrypted-lv /home partition scenario to wrok :)	15:49
kparal	ack	15:49
tflink	dlehman: do you think it would be reasonable to require creating a new layout with btrfs/lvm/md @ beta would be reasonable, leaving reuse for final?	15:49
adamw	#agreed the modified proposed criteria given at XX:37 in the log are approved as the baseline requirements for F18 beta, further requirements have been suggested but will be discussed separately	15:50
tflink	that gets hard to write out in any reasonable way, though	15:50
Viking-Ice	dlehman, any particular reason we should be single out re-use as a special feature until you guys have though things through on how you would like to have it in the end ( which means we could just scrap any kind of criteria around it for F18 )	15:50
adamw	tflink: not really, i could add it to the wording of 2a) easily enough	15:50
dlehman	tflink: probably, yes. I won't sign anything saying as much until I have time to reflect on it further, though.	15:50
adamw	:P	15:50
adamw	it's not just whether it's reasonable, though, it's the basic question of 'does all that really need to work in a Fedora beta'.	15:51
adamw	anyhoo, we have a baseline now at least	15:51
adamw	and this is taking a while	15:51
adamw	shall we move on to the upgrade criterion? which with any luck should be easier	15:51
tflink	dlehman: ok, I wasn't looking for anything definitive today - mostly wondering whether the idea was unreasonable	15:52
adamw	#action adamw to propose a criterion covering basic (not advanced) re-use of /home for Beta	15:52
tflink	adamw: yeah, that proposal has been pretty quiet as of late	15:52
adamw	#info viking-ice suggests that for f19+, much more custom partitioning functionality should be required at Beta	15:53
* adamw trying to capture the major thoughts from the partitioning discussion for the record, any others?		15:53
tflink	adamw: the idea of requiring new lvm/md/btrfs for beta while leaving the reuse/modification of existing layouts for final?	15:54
* jreznik is ok for now, a little bit harder to follow you here...		15:54
adamw	#info there is some support for requiring creation of LVs/advanced btrfs partitions/RAID to work at beta	15:54
adamw	tflink: did you want a definite #action or is it OK to leave it vague?	15:54
Viking-Ice	I prefer vague	15:55
tflink	adamw: I'm fine with it being vague as long as we don't forget entirely	15:55
adamw	tflink: well it'll be in the meeting summary. only #actions are 'guaranteed' to get picked up on later though, in the sense that they get covered at the next meeting.	15:55
adamw	#chair tflink kparal viking-ice	15:55
zodbot	Current chairs: adamw kparal tflink viking-ice	15:55
adamw	now you can #action yourself if you like :)	15:56
adamw	#topic Release criteria: upgrade criteria proposal	15:56
adamw	#info tflink quoted the current proposals at https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html	15:56
adamw	basically, for beta it must be possible to upgrade with any 'officially recommended upgrade mechanism', at final they all have to work.	15:57
adamw	as things stand i think we will only have one 'officially recommended upgrade mechanism' for f18 anyway, so it's kinda moot, but hey	15:57
adamw	anyone want to propose changes to it that haven't already been discussed?	15:57
* adamw +1 to the proposal		15:58
tflink	+1	15:58
Viking-Ice	we kinda have to decide how far back we expect official upgrade is supposed to work	15:58
adamw	Viking-Ice: as these are applied to f18, as I understand the current plan, it pretty much means 'upgrade has to work at beta'.	15:59
adamw	which is what we had previously.	15:59
adamw	i think we have pretty solid agreement that that's what we want, a lot of the discussion was just covering loopholes and making the wording apply when it's not anaconda doing the upgrading.	15:59
Viking-Ice	I'm ack on the proposal but we still need to add how far back release upgrades are supposed to be supported	16:00
adamw	oh right	16:00
adamw	iswym	16:00
Viking-Ice	mean do we support upgrading from F1 to F18 beta?	16:00
tflink	I think that the current wording of "previous stable release" is pretty clear - Fn-1 to Fn only	16:00
adamw	with the current proposal it's the same as the previous one: we only support F(n-1)	16:00
adamw	as far as f18 is concerned it probably makes sense not to change that now	16:00
adamw	if we want to support n-2 we should probably make that f19 stuff	16:01
tflink	agreed	16:01
adamw	but you're right we still need to determine that	16:01
tflink	that seems a bit much to change right before freeze	16:01
adamw	and make other documentation consistent with whatever we ultimately agree development/qa will care about	16:01
adamw	#info viking-ice points out that the question of the status of upgrades from older Fedora releases has still not been entirely settled	16:02
nirik	I could have sworn we had a packager guideline about caring about N-2... but nothing saying what upgrades were "supported"	16:02
nirik	perhaps we could have N-1 as blocker, and N-2 as NTH? :) (but perhaps thats f19 as you said)	16:03
adamw	nirik: as far as QA is concerned we've had the criterion written as 'the previous release' ever since f12, and we've only enforced that (we have a test for n-2 but it's optional and rarely actually performed)	16:03
nirik	yeah	16:03
Viking-Ice	it makes sense we support N-2 as in F16 being supported to be upgraded to F18	16:03
nirik	Viking-Ice: yeah, I agree with that too.	16:03
tflink	the counter to that is stuff like usrmove and if it would be a problem to support multiple upgrade vectors	16:04
adamw	Viking-Ice: i'm kinda torn - i think it's probably correct that we should change and support N-2, but i'm not sure we should do it for F18 since it's pretty late now	16:04
Viking-Ice	adamw, our lazyness not testing it is no excuse ;)	16:04
adamw	Viking-Ice: i'd definitely be on board with supporting F17-F19 and onwards, but i'm a bit unsure about F16-F18	16:04
adamw	anyone else?	16:05
Viking-Ice	could be a final upgrade criteria	16:05
tflink	either way, I'm against requiring n-2 upgrades for F18 - it's too late in the release cycle to be making changes like that	16:05
adamw	Viking-Ice: ironic, usually you're the one saying we should only change for future cycles and i'm the one saying we should change now :)	16:05
kparal	I don't think upgrade from n-2 is a good idea at all, so I wouldn't definitely change that for F18	16:05
adamw	anyway, again we can at least accept that we want *at least* the current proposal	16:06
adamw	which is the important thing for the 'should we freeze' discussion	16:06
adamw	so...	16:06
Viking-Ice	let's clarify that then for F19	16:06
Viking-Ice	ack on the current proposal	16:06
* tflink is still +1 for current proposals		16:06
adamw	propose #agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted	16:06
tflink	ack	16:06
Viking-Ice	ack	16:06
kparal	ack	16:07
* nirik re-reads		16:07
adamw	#info there is some support for extending the criteria to support upgrades from the two previous stable releases, we will discuss that separately	16:07
nirik	so is the 'or' in final intended?	16:07
tflink	wait, does that link point to the actual criterion proposal?	16:07
tflink	it contains them, nvm	16:07
adamw	nirik: what 'or'?	16:07
adamw	oh	16:07
adamw	hm.	16:08
nirik	minimal or blocking desktop	16:08
adamw	it's meant to mean 'all of these', not 'any of these'	16:08
adamw	'or' is a bit ambiguous	16:08
nirik	shouldn't that be 'minimal and all blocking desktops' ?	16:08
adamw	the problem with 'and' is it makes it sound like 'you have to be able to upgrade a system which has both GNOME and KDE installed'	16:08
adamw	making the wording completely clear seems a bit tricky, shall we agree with the intent and try to refine the wording later?	16:09
* tflink wonders if we should have some definition of 'release blocking package sets' elsewhere in the criteria		16:09
adamw	tflink: we define 'release-blocking desktops' in the preamble	16:09
adamw	oh, iswym, that might work	16:10
Viking-Ice	we should not be supporting multiple *de installs et al from my pov	16:10
adamw	nirik: is that OK with you or do you want to nail down the wording now?	16:10
adamw	Viking-Ice: yeah, that's not the intent here, which is why i don't just want to replace 'or' with 'and	16:10
nirik	sure. I think we all agree on intent.	16:10
Viking-Ice	yup	16:10
* kparal back in a few minutes		16:10
nirik	the set of: minimal and (seperately) each release blocking desktop	16:10
nirik	or something	16:10
adamw	'yeah, something like that, but more elegant :)	16:11
nirik	right	16:11
adamw	#agreed tflink's proposal for upgrade criteria, https://lists.fedoraproject.org/pipermail/test/2012-October/110512.html , is accepted (but we note that the use of 'or' is slightly ambiguous and can be improved)	16:11
Viking-Ice	ack	16:11
nirik	ack	16:11
adamw	#agreed the intent of the proposed criteria is that you must be able to upgrade all three of: a) a minimal install, b) a GNOME install, c) a KDE install	16:11
adamw	(just so we have that clearly noted)	16:11
adamw	alrighty!	16:12
tflink	adamw: how can you have minimal, gnome and kde installed at the same time?	16:12
tflink	:-D	16:12
* tflink ducks		16:12
* adamw throws things at tflink		16:12
adamw	d'oh, you're way ahead of me	16:12
adamw	ok, this is really dragging on, so let's move straight to the pre-freeze discussion	16:12
adamw	#topic Fedora 18 Beta status: freeze-worthy?	16:12
Viking-Ice	nope	16:13
Viking-Ice	we need to delay the freeze until the upgrade tool is in place	16:13
tflink	there's a bunch of stuff that I haven't even tried to poke at yet	16:13
adamw	#info FESCo will be determining this week if the F18 codebase, especially anaconda, is complete enough to enter freeze for Beta	16:13
adamw	#info the idea is that we freeze only once the code required by the Beta criteria is broadly in place	16:14
tflink	but I would agree that without a testable upgrade tool, there's little point in entering freeze	16:14
adamw	yeah, i agree with that too	16:14
nirik	freeze is scheduled to start 2012-10-09 currently.	16:14
* nirik nods.		16:14
adamw	it's noted on the FESCo ticket that the upgrade tool code technically exists: https://github.com/wgwoods/fedup	16:14
adamw	but afaik there has been no release yet, and i don't know if it's in working state.	16:14
adamw	dlehman: do you have any info there?	16:15
Viking-Ice	wwoods, around?	16:15
dlehman	no idea about the upgrade tool	16:15
adamw	nirik: fesco is looking at it this week right, though? since next week's meeting will be 10-10	16:16
nirik	I think so... let me look	16:16
adamw	dlehman: the other thing that we just agreed, that i'm not sure of the status of: error handling	16:16
nirik	yes, it should be this week.	16:16
adamw	#info the new upgrade tool code is at https://github.com/wgwoods/fedup , but as far as we are aware there has been no release and no indication that it is yet in testable state	16:17
adamw	dlehman: is error handling in yet? i.e. will anaconda still just crash if you do something wrong in custom part?	16:17
tflink	I would argue that we need ~ 24 hours to poke at any released upgrade tool before determining whether it's testable	16:17
dlehman	adamw: error handling is largely complete during configuration, but we haven't done much for errors that occur during actual install	16:17
Viking-Ice	tflink, atleast 24 hours	16:18
adamw	dlehman: well the criterion covered partitioning specifically, so if we're handling errors during custom part that's probably okayish.	16:18
tflink	Viking-Ice: to determine whether it's testable or not? a week would be awesome but I'm not sure how practical any of that is	16:18
* wwoods is around		16:18
adamw	dlehman: would you say that right now the partitioning code broadly covers the criteria we agreed earlier? i don't think 'autopart to empty space' was working in 18.10	16:18
adamw	wwoods: what's the current state of fedup?	16:19
tflink	that seems rather unfortunately named, but as long as it works ...	16:19
wwoods	it's a work in progress. it'll be testable soon.	16:19
adamw	tflink: i suspect humour	16:19
adamw	wwoods: can you put a date on 'soon'?	16:19
wwoods	it's short for "Fedora Upgrader", obviously	16:19
wwoods	adamw: no.	16:20
wwoods	or: "before the freeze"	16:20
dlehman	adamw: yes, the criteria are largely covered as of now.	16:20
tflink	adamw: as do I, but the meaning of "fed up" has other connotations which don't inspire confidence	16:20
Viking-Ice	that kinda answers that	16:20
Viking-Ice	we delay the freeze	16:20
wwoods	okay so here's more info.	16:21
wwoods	the CLI frontend is basically done, at least for a beta of a 1.0 release	16:22
wwoods	the GUI is coming along	16:22
wwoods	the actual upgrade part needs to be tested a bit to figure out whether we can reliably run the upgrade from system-update.target	16:22
wwoods	otherwise we'll run it from an external system image like anaconda used to	16:23
wwoods	I've been talking to mizmo a bit about a plymouth progress screen for the upgrade	16:24
wwoods	should have something testable.. sometime before the freeze, which I understand to be 10/10	16:24
adamw	okay	16:25
adamw	#info wwoods says fedup should be testable before freeze	16:25
tflink	is the decision to delay freeze being made @ FESCo on wednesday, or just discussed?	16:25
adamw	wwoods: it's 10/9 not 10/10.	16:25
adamw	tflink: not sure	16:25
wwoods	ah, yep. that's what I have on my calendar.	16:25
adamw	#info dlehman says current partitioning code covers the criteria as accepted earlier in the meeting	16:25
adamw	so...i'd say we think the current state of things isn't freeze-able	16:26
adamw	but if fedup is indeed testable by 10/9 we'd say that is freeze-able	16:26
tflink	adamw: agreed	16:26
adamw	right?	16:26
adamw	anyone have any other areas they're worried about for beta freeze, any other requirements i missed?	16:26
tflink	PXE	16:26
Viking-Ice	that can mean alot of things are you refering to kickstart installs ?	16:27
adamw	oh, that's beta isn't it, what's the status of that?	16:27
dlehman	adamw: device encryption is still in development	16:27
tflink	adamw: not sure, haven't gotten around to trying it yet	16:27
adamw	Viking-Ice: general topic, is anyone aware of any other major features of anaconda that would be required to be in place by the beta criteria but aren't yet written	16:27
adamw	Viking-Ice: we're talking major features that aren't done yet, like the upgrade code, not just beta blocker bugs - it's fine for blockers to exist at freeze time, but we want the code to be at least _written_	16:28
Viking-Ice	adamw, tflink mentioned PXE	16:28
tflink	how are we defining testable for upgrade - something that compiles and starts to run?	16:28
adamw	yeah	16:28
adamw	tflink: my wibbly concept is 'the code is there'	16:28
kparal	PXE with http repo works	16:29
kparal	I couldn't test nfs repo yet	16:29
adamw	that sounds freezeable to me	16:29
adamw	(for pxe)	16:29
Viking-Ice	yup	16:29
tflink	did nfs work for alpha?	16:29
kparal	no	16:29
kparal	there is a bug somewhere around I intend to verify	16:30
tflink	that would be another area of concern unless someone else has tried it	16:30
tflink	OK, it sounds addressed, at least	16:30
kparal	but I was sick for the last few days so I didn't get to it	16:30
tflink	serial console?	16:31
adamw	i think that's in	16:31
adamw	ok so how about this	16:31
adamw	propose #agreed QA agrees that the current state of F18 is not freezeable but anaconda team believes outstanding issues will be resolved before freeze. we will list specific areas of concern on the FESCo ticket: upgrade tool and autopart install into free space	16:32
Viking-Ice	ack	16:33
kparal	sounds good	16:33
tflink	that works	16:33
adamw	#agreed QA agrees that the current state of F18 is not freezeable but anaconda team believes outstanding issues will be resolved before freeze. we will list specific areas of concern on the FESCo ticket: upgrade tool and autopart install into free space	16:36
adamw	ok, i have to run right now	16:36
adamw	tflink/kparal, can you take over?	16:36
adamw	either wind things up or do a blocker review, whatever people feel like	16:36
tflink	yeah, can do	16:37
kparal	I would prefer leaving the blocker review to wednesday	16:37
Viking-Ice	yup	16:37
tflink	we're already at 1.5 hours, do we really want to do a blocker review?	16:37
tflink	sounds like not so much :)	16:37
Viking-Ice	;)	16:37
tflink	but reviewing blocker bugs is _so_ much fun ...	16:38
tflink	if there are no objections, we can move on to open floor	16:38
Viking-Ice	let's move to open floor	16:38
tflink	#topic Open Floor	16:39
* kparal moves to the dance floor		16:39
* Viking-Ice points out that nobody dances on monday's		16:39
tflink	Anything else before we finish up?	16:39
tflink	sounds like someone has a case of the "mondays"	16:40
* tflink will hopefully be sending out a testing request for the devel version of the blocker tracking app this week		16:41
Viking-Ice	do the countdown	16:41
tflink	if there's nothing else - I'm setting the fuse for [0,5] minutes	16:41
tflink	Thanks for coming everyone!	16:44
tflink	#endmeeting	16:44

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