QA/Meetings/20121022

From FedoraProject

Jump to: navigation, search

Contents

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!