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