QA/Meetings/20121022

Attendees

• adamw (138)
• tflink (101)
• kparal (73)
• jreznik (30)
• Martix (19)
• cmurf (16)
• zodbot (9)
• mkrizek (4)
• wsirc_4772732 (4)
• jskladan (3)
• maxamillion (1)

Agenda

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

Previous meeting follow-up

• tflink try again with asking other teams to review the updated release criteria - tim forgot about this, he'll do it now
• adamw to update fesco freeze ticket - this was done

Fedora 18 Beta status / mini blocker review

• The new upgrade tool was still not ready, Will says he will have it ready this week if all goes well
• Agreed that QA still could not recommend freezing for Beta as new upgrade tool is still not available for testing: we would pass this recommendation to FESCo but recognize FESCo may go against the recommendation due to time pressures
• TC6 seemed a decent build, we would continue with the validation testing

Mini blocker review

• #866519 was accepted as a blocker per RAID partitioning criterion
• #867296 was left undetermined until further data could be obtained
• #868777 was left undetermined until further data could be obtained

Release criteria / test cases

• Adam was still working on the partitioning criteria, general agreement at the meeting that requirements for custom partitioning should not be heavy at beta time
• Many test cases still needed revising for newui, if you feel like helping out, please do

Open floor

N/A

Action items

• adamw to report recommendation to fesco ticket

IRC Log

adamw	#startmeeting Fedora QA meeting	15:00
zodbot	Meeting started Mon Oct 22 15:00:08 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.	15:00
zodbot	Useful Commands: #action #agreed #halp #info #idea #link #topic.	15:00
adamw	#meetingname fedora-qa	15:00
zodbot	The meeting name has been set to 'fedora-qa'	15:00
adamw	#topic roll call	15:00
* kparal joins		15:00
adamw	morning folks	15:00
* jreznik is ready		15:00
* mkrizek is here		15:00
jreznik	morning adamw! /me would sleep...	15:00
* tflink is present		15:01
adamw	don't worry, i pretty much am.	15:01
* wsirc_4772732 is watching.. :-)		15:02
adamw	#topic previous meeting follow-up	15:02
adamw	" tflink try again with asking other teams to review the updated release criteria " - what happened there, tim?	15:02
tflink	forgot, again. writing email now	15:03
* Martix is here		15:03
adamw	#info "tflink try again with asking other teams to review the updated release criteria" - tim forgot about this, he'll do it now	15:03
adamw	#info "adamw to update fesco freeze ticket" - I did that	15:04
adamw	#topic Fedora 18 Beta status / mini blocker review	15:04
adamw	well, it's groundhog day again, folks	15:04
maxamillion	it is?	15:04
adamw	it is	15:04
adamw	we're still on Beta TCs and we're still waiting for the new upgrade tool.	15:05
jreznik	it is, for me the latest status from wwoods looks like we can be happier this time	15:05
jreznik	wwoods: are you around?	15:05
kparal	should we start creating backup plans?	15:05
adamw	could you report that again for the meeting?	15:05
tflink	jreznik: something testable and packaged?	15:05
adamw	tflink: no, but there's GOING to be, honest guv, we really mean it this time.	15:05
kparal	what the 'contingency' section of our feature page says?	15:05
jreznik	tflink: not packaged but should be in the state "ready for qa to take a look on"	15:05
jreznik	kparal: but I'm +1 for creating backup plan	15:06
tflink	sounds like I know what I'm going to be doing today :)	15:06
tflink	I'm not sure what we can do other than ship beta w/o upgrade	15:06
tflink	or endorse yum upgrades	15:06
adamw	kparal: 1) there is no feature page for this, it's part of anaconda newui. 2) anaconda newui feature explicitly says there is no contingency plan after a merge into rawhide. to sum up, the contingency plan says "suck it".	15:07
tflink	but then again, I'm not the upgrade tool expert	15:07
kparal	right, yum updates	15:07
adamw	yeah, yum is our only option.	15:07
kparal	if yum upgrade works reasonably enough, it can be a backup plan	15:07
* jreznik definitely tend to freeze now, we already avoided two weeks of being frozen...		15:07
jreznik	at least to have some "force" basis to push things forward	15:08
tflink	jreznik: I'm not sure I follow you if nothing has changed from the last 2 weeks - same state	15:08
adamw	the only problem i have with that is that we have to be clear we're making such a decision entirely and only due to time pressure, there's no other reason to make a different decision this week than we did last week	15:08
adamw	(that applies to QA and to fesco)	15:08
jreznik	adamw: yep, from this side - there's no, it's not done - on the other hand, latest status gives some chance that there was some move and with some luck, we can have it this week	15:09
adamw	well, okay. there's will saying he's sure he'll get it done THIS week. but then it was planned to be done the week before and also last week, so pardon me for not placing a high reliability value on said prediction :)	15:09
tflink	adamw: +1 - nothing against will but upgrades are complicated. I'd hesitate freezing this week even if we get something testable today - who knows what issues are lurking	15:10
adamw	i think personally i'd like to be awkward and recommend a slip again	15:10
adamw	fesco of course can go against our recommendation...i think if it's anyone's job to be considering time pressure and voting for fudges it's fesco's, not ours.	15:10
kparal	F18 will be the most polished release ever :)	15:10
adamw	what does everyone else think?	15:11
tflink	we could freeze and move go/no-go up a week, I suppose if the matrices are in good shape (haven't checked TC6 yet)	15:11
* jskladan is here		15:11
tflink	+1 freeze slip	15:11
wsirc_4772732	+1 freeze slip	15:11
adamw	whoever signed in via webirc can you identify yourself, just so we know who you are in the logs? thanks :)	15:12
Martix	F18 should enter freeze	15:12
adamw	#info new upgrade tool is still not ready, Will says he will have it ready this week if all goes well	15:12
kparal	I have no really hard opinion here. fedup looks like a pony, having yum as a Beta backup and freezing doesn't sound that bad	15:12
adamw	kparal: then why didn't we do that last week or the week before?	15:12
Martix	kparal: +1	15:12
* wsirc_4772732 is t.bubeck@reinform.de a fedora ambassador and packager. Sorry, but I am on customer site..		15:12
kparal	adamw: because we believed it would be done soon	15:12
adamw	wsirc_4772732: no problems, thanks :)	15:12
jreznik	kparal: yep, I tend more trying a backup option	15:12
Martix	adamw: because we had faith in empty promises from fedup developers :-)	15:13
adamw	@info wsirc_4772732 is t.bubeck	15:13
adamw	grr	15:13
adamw	#info wsirc_4772732 is t.bubeck	15:13
jreznik	Martix: yep...	15:13
jreznik	I asked kparal last week to prepare on the backup solution :)	15:13
adamw	okay. well, i mean, we've always had yum.	15:13
adamw	my problem with yum is more about messaging than optics - we've always said that yum isn't a supported/recommended upgrade option and people should use the 'proper' tools because yum can't possibly handle upgrades 100% reliably.	15:14
adamw	now when our proper tool isn't done we're like 'oh, just use yum, it'll be fine'? eh.	15:14
kparal	adamw: I agree, it seems like a Fedora failure	15:14
Martix	adamw: we can test yum and try to fix issues	15:14
kparal	but this whole situation is a sort of a failure	15:15
tflink	adamw: agreed about the messaging	15:15
* jreznik understands... but are we willing to wait month for the tool? two, three? ;-)		15:15
Martix	or find workaround which will work for everybody	15:15
Martix	*workarounds	15:15
adamw	jreznik: like i said, i see that as a fesco issue, not a QA one.	15:15
tflink	jreznik: that's a good question but not a QA issue	15:15
adamw	jreznik: we're making a recommendation based on QA considerations, time pressure is your consideration.	15:15
kparal	the first time we postponed freeze, we should have set a maximum wait deadline	15:15
jreznik	adamw, tflink: yep, it is - but I'd like to offer fesco an alternative - if QA could help with testing...	15:16
tflink	kparal: why? How is that different from voting every week	15:16
adamw	jreznik: well, the alternative is as discussed, unfreeze and have yum as a backup plan. yum upgrade is already pretty well documented.	15:16
kparal	tflink: because then adamw asks - what is different this week? :)	15:16
adamw	=)	15:16
adamw	i'm always the awkward one	15:16
tflink	jreznik: I'll help test whatever we need to but I'm against accepting yum as a recommended upgrade method	15:16
adamw	if we don't have consensus i can write a split recommendation in the fesco ticket and we can dump it on them. it's their fault for not running the feature process properly anyway. =)	15:17
jreznik	tflink: fair enough	15:17
kparal	from QA standpoint, as adamw puts it, yes, postponing freeze is better	15:17
adamw	or we can say that from a QA standpoint we recommend slip but we recognize FESCo may consider time issues that we don't	15:17
* jreznik does not want to influence QA decision based on time pressure...		15:17
kparal	and we also agree that there is a working alternative - yum	15:18
kparal	even though controversial	15:18
tflink	is it really wise to put off upgrade testing until final"	15:18
Martix	btw what fedup is meant to do better then yum distro-sync+permissive selinux?	15:18
kparal	tflink: I wonder whether yum backup plan would stay also in Final	15:18
jreznik	kparal: I can take that "dirty" thing from your hands	15:18
Martix	we dont have "problem" features like /usr move in F17	15:18
adamw	kparal: as tflink says the issue isn't so much having a working upgrade option	15:18
adamw	kparal: it's about *testing* our upgrade	15:19
tflink	I'd say that we're +1 freeze slip unless fesco endorses yum as a recommended upgrade tool	15:19
kparal	tflink: for F18 Final, right?	15:19
tflink	and I'm not crazy about saying "yum is recommended only for beta"	15:19
tflink	kparal: for beta	15:19
* adamw puts entirely arbitrary 5 minute limit on further discussion		15:20
tflink	I'm very strongly against changing the release criteria just for a beta	15:20
adamw	okay, how about a vote	15:20
tflink	if fesco wants to recommend yum as an upgrade method, fine. I'd like to know who's going to fix any bugs that come up and handle the discussion in F19 about whether or not yum is a recommended tool for upgrade	15:20
Martix	ok, only problem change is DisplayManagerRework	15:21
jreznik	tflink: with offline updates I'd say yum will be never endorsed as recommended tool at all	15:21
adamw	propose #agreed QA still cannot recommend freezing for Beta as new upgrade tool is still not available for testing: we will pass this recommendation to FESCo but recognize FESCo may go against the recommendation due to time pressures	15:21
tflink	jreznik: so we'd be fudging the release criteria for beta and possibly final?	15:22
kparal	ack	15:22
tflink	adamw: works for me	15:22
mkrizek	ack	15:22
tflink	wait, what about beta slips?	15:23
wsirc_4772732	ack	15:23
tflink	do we want to go into freeze without fesco deciding on a backup plan?	15:23
tflink	I'd still rather slip freeze than slip after freeze	15:23
adamw	tflink: want me to patch it to ask fesco to address post-freeze concerns?	15:23
jreznik	tflink: in this wording for fesco ticket it's definitely slip before freeze	15:24
tflink	adamw: yeah	15:24
tflink	jreznik: I'd still rather slip before freeze than during	15:24
adamw	tflink: i can add it as a #info it'd be too long for the #agreed	15:24
jreznik	tflink: yep, it's all we are talking about right now	15:24
tflink	if we're going to still slip for the upgrade tool, I don't see how entering freeze now is any better than slipping freeze and pushing go/no-go up a week	15:25
jreznik	otherwise we would go through the standard go/no-go process without the fesco approval	15:25
adamw	so we want fesco to have a definite plan for shipping without the upgrade tool being ready, if it votes to freeze now	15:25
adamw	i can note that.	15:25
adamw	#agreed QA still cannot recommend freezing for Beta as new upgrade tool is still not available for testing: we will pass this recommendation to FESCo but recognize FESCo may go against the recommendation due to time pressures	15:25
tflink	adamw: a second #agreed for that?	15:26
adamw	#info if FESCo votes to freeze now we would like them to have a definite plan for how Beta can be shipped without the upgrade tool ready, we do not want to see post-freeze slips due to the upgrade tool	15:26
adamw	tflink: i think it's okay as an info?	15:26
tflink	ok	15:26
tflink	jreznik: are you updating the fesco ticket?	15:26
Martix	tflink: consider other devel teams which takes advantage of opened window before freeze and trying to push more feature which could break F18 more	15:26
adamw	#action adamw to report recommendation to fesco ticket	15:27
jreznik	tflink: I can do it, for sure	15:27
adamw	Martix: they shouldn't be pushing anything major outside of the feature process.	15:27
tflink	Martix: sure, that's possible but it hasn't seemed to happen yet. is that really all that worse than freezing for 3-5 weeks?	15:27
jreznik	adamw: should not...	15:27
tflink	and if something bad gets pushed, it can be fixed during freeze or unpushed	15:28
tflink	unpushed/undone etc.	15:28
jreznik	tflink: it's more about finding the right point when disadvantages kills all advantages get by non freezing	15:28
tflink	if it's something that's not undoable and can't be fixed during freeze, I think we're in trouble no matter what	15:28
Martix	adamw: tflink I heard from some devs that they like freeze slip because they have more time for pushing new code to F18	15:28
tflink	Martix: that was part of the point for slipping freeze	15:29
tflink	so that other development isn't held up	15:29
jreznik	to not disrupt devels	15:29
tflink	and we don't end up in the same situation as alpha "we've been frozen too long already, just ship the damn thing"	15:29
adamw	i think we're just skating over old ground here	15:30
jreznik	and I'm trying to talk to the people doing bigget changes to be more conservative	15:30
adamw	any objections to moving on?	15:30
jreznik	adamw: move on ;-)	15:30
tflink	no, I think we've covered the QA related stuff well, the rest of it is PM	15:30
adamw	okay	15:30
adamw	#info Beta TC5 and TC6 came out over the weekend	15:30
adamw	anyone have any headline news from TC5 or TC6 testing?	15:30
kparal	works reasonably it seems	15:31
adamw	i don't see any showstopping fails	15:31
kparal	NM crashes are gone	15:31
jreznik	works quite good for me	15:32
adamw	okay, cool	15:32
mkrizek	so far so good for me too	15:32
adamw	#info TC6 seems a decent build, we will continue with the validation testing	15:32
Martix	I got crash when removing old partitions, but unable to reproduce it	15:33
jreznik	I just hit the reclaiming issues - kparal is right, preserve/delete is really confusing	15:33
adamw	there's a lot of fixed blockers to verify so please everyone check through that list	15:33
adamw	and provide karma on the anaconda update so we can push it stable	15:33
adamw	that'll clean out a lot of stuff from the blocker list	15:33
Martix	too many option permutations to test and just some crashes :-/	15:33
adamw	#info please provide + karma for the anaconda update if TC6 is working reasonably for you	15:33
kparal	anaconda is already going stable	15:34
adamw	ah okay, cool	15:34
adamw	#undo	15:34
zodbot	Removing item from minutes: <MeetBot.items.Info object at 0x22677e90>	15:34
adamw	tflink, do you want to go through the proposed blockers quick?	15:34
adamw	note I just added the VNC bug to the proposed blocker list	15:34
adamw	that's https://bugzilla.redhat.com/show_bug.cgi?id=868777	15:34
tflink	adamw: sure but I don't see much to go through	15:34
adamw	#chair tflink kparal	15:34
zodbot	Current chairs: adamw kparal tflink	15:34
adamw	866519 looks like it could be voted on	15:35
* tflink is skipping all the upgrade related bugs		15:35
tflink	#topic (862784) newUI custom partitioning does not allow formatting of an existing partition for use in the installed system	15:36
tflink	#link https://bugzilla.redhat.com/show_bug.cgi?id=862784	15:36
tflink	#info Proposed Blocker, anaconda, NEW	15:36
adamw	this is kinda tied to the partitioning criteria revie	15:36
adamw	w	15:36
adamw	personally i'm not in favour of requiring this to work for beta, there's too many other ways to do it	15:36
tflink	yeah, I should have skipped it	15:36
tflink	#undo	15:37
zodbot	Removing item from minutes: <MeetBot.items.Info object at 0x176259d0>	15:37
tflink	#undo	15:37
zodbot	Removing item from minutes: <MeetBot.items.Link object at 0x291e67d0>	15:37
tflink	#undo	15:37
zodbot	Removing item from minutes: <MeetBot.items.Topic object at 0x2e60b990>	15:37
tflink	#topic (866519) BIOS RAID is not shown on harddrive screen	15:37
tflink	#link https://bugzilla.redhat.com/show_bug.cgi?id=866519	15:37
tflink	#info Proposed Blocker, anaconda, NEW	15:37
tflink	we're already +2 blocker on this (adamw, tflink) from bz	15:37
Martix	+1 betablocker	15:38
tflink	proposed #agreed 866519 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"	15:38
adamw	ack	15:39
mkrizek	ack	15:39
tflink	anyone else?	15:39
kparal	I read quickly, but seems like ack	15:40
adamw	it's pretty straightforward, yeah.	15:40
kparal	ack	15:40
tflink	#agreed 866519 - AcceptedBlocker - Violates the following F18 beta release criterion: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot"	15:40
tflink	#topic (867296) NameError: global name 'gtk_call_once' is not defined	15:41
tflink	#link https://bugzilla.redhat.com/show_bug.cgi?id=867296	15:41
tflink	#info Proposed Blocker, anaconda, ON_QA	15:41
kparal	this was verified already	15:41
tflink	it was?	15:42
kparal	with no comment	15:42
kparal	yes, look at History	15:42
adamw	we still have no information on this	15:42
adamw	dan verified it.	15:42
adamw	i'm happy just to punt on this again and let it die a natural death...	15:42
tflink	but it's still ON_QA	15:42
tflink	oh, I see	15:42
tflink	works for me	15:43
kparal	it's the Bodhi madness	15:43
adamw	i've filed a ticket on Bodhi doing that, btw.	15:43
kparal	adamw: can you send me a number or CC me?	15:43
tflink	proposed #agreed 867296 - There is still not enough information on this to decide on blocker status, will re-visit when there is more information available	15:43
kparal	let's skip all verified bugs?	15:43
kparal	ack	15:44
adamw	kparal: will do	15:44
adamw	ack	15:44
Martix	agreed	15:44
tflink	kparal: that's generally the plan but it didn't show up as VERIFIED when I started	15:44
tflink	#agreed 867296 - There is still not enough information on this to decide on blocker status, will re-visit when there is more information available	15:44
kparal	tflink: yes, most of them is not verified, because Bodhi switched it all to ON_QA	15:45
tflink	kparal: we can skip all the accepted blockers	15:46
tflink	#topic (868777) fail to install the system use vnc	15:46
tflink	#link https://bugzilla.redhat.com/show_bug.cgi?id=868777	15:46
tflink	#info Proposed Blocker, anaconda, NEW	15:46
tflink	how often is this happening?	15:47
adamw	if this is timing-based then that complicates things, but it looks pretty blockery	15:47
adamw	"How reproducible:	15:47
adamw	sometimes - depends on dhcp lease"	15:47
tflink	I wonder how many people are doing VNC + media	15:47
kparal	quite a few, I think. at least some of my colleagues	15:48
kparal	with remote servers	15:48
tflink	if the server is remote, how are they using media?	15:48
kparal	cobbler or something	15:48
tflink	but that's not media based	15:48
kparal	hmm, right, I'm not fully sure it is netinst	15:49
tflink	with the information we have, I'm not -1 but I'm not fully +1, either	15:49
tflink	I'd like to see more testing with PXE	15:49
adamw	what more info would you like to have?	15:49
kparal	I can do that	15:49
tflink	if it's just media + vnc + dhcp, I'm not sure this is a clear blocker	15:50
kparal	I think it is a full-fledged blocker	15:50
kparal	but I can re-test with pxe boot	15:51
adamw	i'm okay to go along with that.	15:51
tflink	I'm not -1 blocker, I'm just not sure about slipping if this was the last blocker at go/no-go	15:51
kparal	hmm, it might not related to PXE, because PXE boots from network	15:52
kparal	that's why comment 4 says only media	15:52
kparal	with PXE your network is already up	15:52
tflink	potential workarounds: use static IP during install, use monitor (if you have access to do media, you probably have physical access and don't 100% need VNC)	15:52
tflink	kparal: yeah, that's what I was wondering - PXE gets an ip before booting the installer env	15:53
kparal	but booting from kernel pair in VM could trigger it	15:53
kparal	but VM has probably very fast dhcp	15:53
tflink	good point	15:53
kparal	unless you have it bridged	15:53
tflink	any other votes?	15:53
kparal	and I don't	15:53
tflink	I see an implicit +1 from kparal and a +/- 0 from me	15:54
adamw	i'm with tflink	15:54
kparal	that means I still win :-) no, really, what that means, punt?	15:55
tflink	proposed #agreed 868777 - More information is needed before making a decision on blocker status - are PXE and other remote boot methods affected by this bug? What percentage of installs hit this?	15:55
kparal	patch	15:56
kparal	does static IP assignment work?	15:56
kparal	might be a good question to ask	15:56
tflink	proposed #agreed 868777 - More information is needed before making a decision on blocker status - are PXE and other remote boot methods affected by this bug? What percentage of installs hit this? Is using a static IP a valid workaround?	15:56
adamw	ack	15:56
kparal	ack	15:57
tflink	#agreed 868777 - More information is needed before making a decision on blocker status - are PXE and other remote boot methods affected by this bug? What percentage of installs hit this? Is using a static IP a valid workaround?	15:58
adamw	i think we lost everyone else	15:58
tflink	yeah, do we want to go through the accepted blockers that aren't ON_QA or VERIFIED?	15:58
adamw	no	15:59
adamw	we never do at this meeting, just proposed	15:59
tflink	ok, works for me	15:59
adamw	we only do the mini review in this meeting to clean out the proposed list	15:59
adamw	so, we have a couple other topics, but if there's only the three of us here, not much point discussing them	15:59
adamw	anyone else around for criteria / test case discussion?	15:59
jskladan	yaay	15:59
jskladan	criteria	16:00
kparal	:D	16:00
* kparal pokes mkrizek		16:00
* cmurf is lurking		16:00
tflink	it'd be nice to have some anaconda folk if we're talking about the partitioning criteria	16:00
adamw	#topic Release criteria / test cases	16:00
adamw	so yeah...i'm still kinda struggling with the partitioning criteria	16:01
adamw	only had one reply to my last mail about the overall approach to take, from cmurf (thanks cmurf)	16:01
adamw	so i'm not sure what the feeling is there	16:01
cmurf	It's a tedious subject that's for sure, I don't envy anyone deeply involved in this.	16:02
adamw	heh.	16:02
adamw	so does anyone have an opinion on whether we really need to be requiring a lot of functionality from custom part at beta at all? aside from me and cmurf?	16:02
* kparal digging through archives		16:04
tflink	define a lot - I like the approach of requiring what we did before regardless of whether it's autopart or not any more	16:04
cmurf	FWIW I'm very conservative / set low expectations for custom partitioning given a whole new installer. My main thought is to test for data loss. That's the scenario most worth avoiding. Functionality I consider icing on the cake.	16:05
tflink	but I'm not really a fan of requiring too much custom partitioning @ beta	16:05
cmurf	tflink: exactly my position	16:05
adamw	kparal: you mean you don't keep all my posts open on your desktop for regular reading?!	16:05
adamw	.fire kparal	16:05
zodbot	adamw fires kparal	16:05
adamw	https://lists.fedoraproject.org/pipermail/test/2012-October/110967.html	16:05
kparal	I pin them to the wall	16:05
adamw	they better be framed	16:05
kparal	I just don't have enough walls, so they are layered	16:05
tflink	I layer my hamster's cage with them :)	16:06
* tflink doesn't actually have a hamster		16:06
cmurf	You guys have enough paper in your printers for this? Or does the shrink setting actually go that low?	16:06
adamw	that's somehow even wrose.	16:06
adamw	that's right. poke the tiger.	16:07
cmurf	haha	16:07
tflink	ooh, tiger ...	16:07
Martix	cmurf: talking about shrinking filesystems...	16:07
cmurf	?	16:08
adamw	so i guess in general folks are in favour of the minimal option, okay.	16:08
* kparal finished refreshing his memories		16:08
Martix	cmurf: is it supposed to work?	16:08
adamw	kparal: wdyt?	16:09
cmurf	Martix: btrfs? I'm not shrinking, I'm trying to migrate extents from a smaller device to a larger one.	16:09
kparal	so what are the criteria we would like to remove/not add to Beta wrt custom partitioning?	16:09
Martix	cmurf: ext4 on LVM	16:09
tflink	I'm not crazy about not requiring LVM/btrfs @ beta but I'm not sure I see much of a place in between	16:09
tflink	but I think that RAID needs to stay	16:10
cmurf	Martix: I haven't tested extensively but it should work.	16:10
adamw	kparal: well the 'new' ones we added a few weeks back	16:10
adamw	kparal: plus all the previous proposals in that thread	16:10
cmurf	tflink: I definitely would not require btrfs, LVM is maybe a slightly different story because it's been around so long, like RAID. But I'm totally dead set against RAID 5 holding up a beta&#8230;FWIW.	16:10
kparal	adamw: so this one? The installer's custom partitioning mode must be capable of the following:	16:11
kparal	Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types	16:11
kparal	Creating encrypted partitions	16:11
kparal	Rejecting obviously invalid operations without crashing	16:11
adamw	kparal: i haven't looked at the precise adjustments	16:11
adamw	kparal: yeah, basically.	16:11
kparal	all erased?	16:11
adamw	it was more a general-approach thing.	16:11
adamw	broadly, yeah.	16:11
tflink	cmurf: I was thinking of LVM/btrfs as more of a one-or-the other kind of thing	16:11
cmurf	The problem with lowering expectations for beta, is that we in effect turn final TC's into beta redux...	16:12
tflink	cmurf: I don't really follow how RAID5/6 is any worse than 0/1	16:12
kparal	that means we wouldn't require Beta to be able to install into dual-boot. because usually you are not satisfied with some ad-hoc automatic disk layout	16:12
tflink	unless mdraid is busted, which I think is blocker worthy	16:12
tflink	kparal: I thought that dual-boot was always a final thing, not beta	16:13
kparal	tflink: I mean install alongside an existing system, I don't really mean windows thing	16:13
cmurf	tflink: btrfs raid0 with boot+root+home as subvols in a single volume, is now bootable with anaconda 18.19	16:14
kparal	I think a lot of people might try to install Beta alongside F17	16:14
cmurf	That exceeds the requirements. I don't know any other arrangement that supports /boot on raid0.	16:14
kparal	if it just says "no" without eating their disk, ... /me shrugs	16:14
tflink	cmurf: I'm still not following you, we don't require /boot on raid	16:15
adamw	kparal: it should be possible to do that via guided partitioning...	16:15
kparal	adamw: but we should have criteria that it doesn't eat their other partitions, even if they use custom part	16:15
kparal	at least no data loss should be checked	16:15
adamw	hmm	16:15
adamw	how would you do that, practically speaking?	16:15
adamw	it's hard to prove a negative	16:16
kparal	well if someone reports a bug that anaconda touched a different partition, we can have it as a blocker	16:16
kparal	of course we can't prove it works	16:16
kparal	we can just block if it doesn't	16:16
adamw	ok	16:17
adamw	thanks for the thoughts	16:17
adamw	i guess we should push on	16:17
adamw	#info adamw still working partitioning criteria, general agreement that requirements for custom partitioning should not be heavy at beta time	16:17
adamw	so on test cases, i really just wanted to note that quite a few still seem to need modification for newui	16:18
adamw	i was planning to get the partitioning test cases updated this week	16:18
kparal	I also plan to work on it	16:18
adamw	if anyone feels like working on an old test case please just do it, and let the list know (as kparal and I did, for an example)	16:18
kparal	but then I spend whole day re-testing blockers :/	16:18
adamw	=)	16:18
cmurf	tflink: I know it's not required today, but for btrfs it may need to be one day soon because it's simply how btrfs makes valid multidevice volumes.	16:20
adamw	#info many test cases still need revising for newui, if you feel like helping out, please do!	16:20
adamw	welp, i guess that's that	16:21
adamw	#topic open floor	16:22
adamw	any more for any more?	16:22
* cmurf will be in Brno Nov 8-13		16:23
cmurf	:-)	16:23
adamw	on tour with the cmurfettes?	16:24
adamw	FINALLY i got to use that!	16:24
adamw	i can die happy now	16:24
* adamw sets fuse for 1 minute		16:25
jreznik	adamw: could you please update fesco ticket so I can add my part? :)	16:26
adamw	#endmeeting	16:26

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