16:00:06 <adamw> #startmeeting Fedora QA meeting
16:00:06 <zodbot> Meeting started Mon Nov 18 16:00:06 2013 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:06 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:10 <adamw> #meetingname fedora-qa
16:00:10 <zodbot> The meeting name has been set to 'fedora-qa'
16:00:17 <adamw> #topic Roll call
16:00:35 <adamw> ahoyhoy folks, who's around for another week of QA swashbucklin'?
16:00:48 * nirik is lurking around in the back
16:00:54 * kparal is around, whatever swashbucklin' is
16:01:01 * mkrizek is here
16:01:25 * roshi is here
16:01:44 * jskladan is lurking
16:01:51 * jreznik is lurking too
16:02:22 <adamw> kparal: first one buckles one's swash, then one swashes one's buckle
16:02:37 * tflink is around, in another meeting, though
16:03:40 * pschindl is here
16:04:27 <kparal> adamw: you're giving my english skills a hard time :)
16:04:39 <adamw> don't sweat it :)
16:04:51 <adamw> #topic Previous meeting follow-up
16:05:06 <adamw> "roshi to help out adamw with CommonsBugs page" - roshi?
16:05:26 <roshi> done
16:05:32 <roshi> though, it's an ongoing process :)
16:05:48 <roshi> so, worked on, I guess would be better phrasing
16:06:09 <adamw> yup
16:06:27 <adamw> #info "roshi to help out adamw with CommonsBugs page" - this was done, roshi and adamw together updated the page for F20 Beta
16:06:40 <adamw> one more for you: " roshi to file Final TC1 compose request"
16:06:43 <adamw> looks like that was also done
16:06:47 <roshi> yup
16:06:50 <adamw> (spoiler alert!)
16:06:55 * pwhalen lurks
16:07:45 * satellit_f20 listening
16:07:47 * adamw notices the worrying amount of lurking going on around this here boat
16:07:50 * adamw grabs harpoon gun
16:08:03 * Viking-Ice 50% in 50% out
16:08:37 <adamw> #info "roshi to file Final TC1 compose request" - done, adamw added another package to the request and it was built on 11-14: https://fedorahosted.org/rel-eng/ticket/5808
16:08:49 <adamw> #topic Fedora 20 Final status
16:09:22 <adamw> so, TC1 is out and in testing
16:09:35 <adamw> we have a fairly long list of accepted blockers that we're still waiting on fixes for, and some proposed blockers from TC1 testing
16:09:53 <adamw> probably early enough in the cycle that we don't need to do a blocker meeting today, unless anyone thinks otherwise?
16:10:08 <kparal> wednesday is fine I think
16:10:22 * Viking-Ice goes checking that list
16:10:22 <roshi> wednesday seems fine
16:10:46 <jreznik> adamw: btw. I plan to send a change deadline reminder tomorrow, could include blockers there too unless you wants to do it so (as you do, but later)
16:10:57 <adamw> jreznik: fine by me
16:11:08 <jreznik> ok
16:12:04 <tflink> as a heads up, we're planning to upgrade the blocker tracking app in the next day or so
16:12:16 <tflink> seemed relevant to discussion around meeting times
16:12:47 <Viking-Ice> yup small enough to wait for Wednesday
16:12:54 <adamw> thanks tflink
16:13:02 <adamw> #info blocker tracking app will be updated 'in the next day or so'
16:13:23 <tflink> we're waiting on an update to be pushed stable
16:13:38 <adamw> i was planning to file the TC2 request today, with the new anaconda build and anything else that looks relevant
16:13:42 <adamw> if that's OK for everyone?
16:14:01 <pwhalen> looks like tc1 is missing quite a few of the arm images
16:14:20 * satellit_f20 is 32 bit installer fixed?
16:14:34 <adamw> i think dgilmore said something about that
16:15:01 <adamw> satellit_: not yet, looks like we got a bit further figuring out what's going on but not all the way yet
16:15:18 <adamw> dgilmore: what was the story with ARM images in TC1?
16:15:51 <pwhalen> Unable to create appliance : Failed to build transaction : yumex-3.0.13-1.fc20.noarch requires python-pexpect
16:16:44 <adamw> right, i recall seeing that error message.
16:17:14 <pwhalen> for those looking to help with arm testing, the installer can be tested using qemu, I've added updated instructions to the wiki for usage, please edit as needed.
16:17:20 <adamw> #info several ARM images failed to compose for TC1 due to yumex dependency issue, will try to ensure it's resolved for TC2
16:18:54 <adamw> there's quite a lot of further test coverage needed, it'd be great to get as much of the matrix as possible done as early as possible
16:19:07 <adamw> even though we have obvious showstoppers atm
16:19:54 <pwhalen> adamw, will cover arm today
16:19:55 <jreznik> would be nice to have as much coverage as early possible, indeed
16:20:01 * satellit_ minor fixes for sugar-runner needed https://bugzilla.redhat.com/show_bug.cgi?id=1030418
16:21:03 * satellit_ http://bugs.sugarlabs.org/ticket/4258  wrong naming in control panel  peter says fixes are available
16:21:41 <adamw> satellit_: thanks
16:21:50 <adamw> as long as pbrobinson is on it, sounds like it'll get fixed
16:21:58 <satellit_f20> sugar has some minor : )
16:23:45 <pbrobinson> adamw: yep, it's a minor annoyance as opposed to any particular issue
16:25:15 <adamw> rockin'
16:25:36 <adamw> #info still lots of gaps in the matrices from TC1 testing, we should aim to get as close to full coverage as we can with TC2
16:25:46 <adamw> #info TC2 request will likely be filed today
16:26:57 <adamw> anything else on Final?
16:28:20 * roshi has nothing
16:28:59 <adamw> moving right along then...
16:29:01 <adamw> #topic Open floor
16:29:12 <adamw> didn't really see any other specific topics worth listing
16:29:22 <adamw> but if you have anything about fedora.next or test days for instance, now's the time!
16:29:43 <tflink> if anyone wants to test the new blockerbugs version, it's available in stg
16:29:48 <tflink> https://qa.stg.fedoraproject.org/blockerbugs/
16:30:10 <Viking-Ice> adamw, the next/wg stuff got put on ice until after new year
16:30:24 <Viking-Ice> we have no clue ( and neither to the WG ) what exactly they want from us
16:30:51 <Viking-Ice> s/to/do
16:31:30 <Viking-Ice> but I would say our stand point is simply installer + what ever comes from the baseWG
16:31:31 <adamw> #info new blocker bugs upgrade is in staging: https://qa.stg.fedoraproject.org/blockerbugs/
16:31:35 <Viking-Ice> rest sub communities
16:31:52 <adamw> Viking-Ice: i think that's a reasonable starting point
16:32:05 <jreznik> I have one topic - adamw recently commented to one Predictable Network Interface Names feature, that it was never implemented at all... I'd like to have some QA coverage on at least system wide changes we have for F20 as we talked about that some time ago... I know, hard times for QA but during release but... I can prepare a list
16:32:24 <adamw> Viking-Ice: but as you say it's pretty difficult to figure out what people are expecting of us at present :/
16:32:29 <Viking-Ice> jreznik, it's implemented the problem the dell stuff did not get removed
16:32:51 <adamw> right, i said it 'effectively wasn't implemented as described' because biosdevname is gazumping it.
16:32:52 <jreznik> Viking-Ice: well, it was just an example...
16:32:53 <Viking-Ice> adamw, we in serverWG have not agreed where we are heading amongst our selves
16:32:58 * satellit_ wish eth0 and wifi names were simpler
16:33:08 <adamw> jreznik: well, my report about that was basically a result of me testing it, as part of us testing major Changes. :)
16:33:28 <Viking-Ice> jreznik, f21 will have systemd-networkd I assume so.. new network units hurray ;)
16:33:28 <jreznik> satellit_: yep, we're maybe oldschoolers :)
16:33:33 <adamw> jreznik: i'd already written in multiple bugs about it, talked to notting about it, etc. that note was just a way of making sure fesco was aware this problem existed.
16:33:34 <jreznik> adamw: well, it's F19 one :D
16:34:02 <jreznik> but still it's good you raised that question
16:34:24 <jreznik> https://bugzilla.redhat.com/buglist.cgi?component=Changes Tracking&product=Fedora
16:34:35 <Viking-Ice> biosdevname should be removed obsoleted/deleted killed gazunked zombified shot stabbed and buried 6 feet under
16:34:46 <Viking-Ice> it's yesterdays news
16:35:14 <adamw> jreznik: of the f20 approved system-wide changes, i'd say really the only ones we haven't covered to some extent which maybe it would be nice to have covered are the new features in NM
16:35:50 <adamw> Viking-Ice: notting's going to commit that for F21 shortly (or he did already)
16:35:54 <jreznik> I expect for NM, there's test day planned, right?
16:36:21 <Viking-Ice> adamw, he should do that for 20 as well
16:36:39 <adamw> jreznik: no, there is no NM test day planned.
16:36:40 <Viking-Ice> jreznik, if either of the Dan's have approach us with it
16:37:01 <Viking-Ice> we do not autocreate test days for features
16:37:12 <adamw> Viking-Ice: i'd really rather not do it this late for F20, it's a bit of a messy area - f19 already burned us - and right now we're moderately confident the f20 behaviour is at least a) predictable and b) sane
16:37:38 <adamw> it's not what we wrote down on the feature page, but at least it's not changing the names of interfaces between installation and boot like f19 was :/
16:38:06 <Viking-Ice> I disagree we should removed it while it's still the chance
16:38:06 <cmurf> adamw: when/where/how to have the btrfs and LVM thinp convo?
16:38:07 <jreznik> ok
16:38:22 <adamw> what 'convo' is this, cmurf?
16:38:41 <jreznik> adamw: conversation?
16:38:49 <cmurf> yes sorry for the lingo, i'm lazy
16:39:00 <adamw> i know what 'convo' is short for
16:39:07 <adamw> i am unclear what conversation you are referring to
16:39:24 <cmurf> the one with dlehman, and whoever else, about making btrfs a tech preview or not
16:39:34 * Viking-Ice had no idea what convo was for thought alcoholic beverage
16:39:35 <cmurf> to at least clarify what things are edge cases, and should be supported
16:39:46 <cmurf> line in the sand so to speak
16:40:06 <adamw> well, if you're talking about f20, 'when' would be 'as soon as possible'
16:40:06 <jreznik> cmurf: we talked with guys a bit in #anaconda but no clear result
16:40:17 <Viking-Ice> I guess after what stunt marketing did we need to cover *all* lvm thinp stuff
16:40:19 <cmurf> adamw: i'm even suggesting that it doesn't need to be for f20
16:40:20 <adamw> 'where' would be '#anaconda or somewhere else anaconda folks are listening'
16:40:36 <adamw> and 'how' would be 'tactfully'? :)
16:40:47 <adamw> Viking-Ice: yeah, point, marketing is clearly involved
16:41:31 <Viking-Ice> adamw, well I would say we wheren't ready for lvm thinp but marketing went ahead and advertized it
16:41:52 <cmurf> was LVM thinp in Rawhide for more than 10 hours before branch?
16:42:09 <cmurf> because it didn't work at all, i mean at all, until beta test candidates
16:42:25 <Viking-Ice> "Cloud and Virtualization Enhancements
16:42:25 <Viking-Ice> OS Installer Support for LVM Thin Provisioning – With the introduction of thin provisioning via Logical Volume Manager (LVM) in the Linux kernel, Fedora 20 can now support the configuration of thin clients during OS installation."
16:42:29 <jreznik> Viking-Ice: what's advertised in alpha/beta notes does not mean it has to be in final
16:42:53 <Viking-Ice> jreznik, I'm pretty sure all RHEL customers http://www.redhat.com/about/news/archive/2013/11/fedora-20-heisenbug-now-available-in-beta-release
16:42:55 <Viking-Ice> disagree...
16:43:37 <Viking-Ice> so I guess what got stated there is that sand in the line cmurf was looking for
16:43:38 <cmurf> anyway, i think the Btrfs and Thinp, line in sand, also relates to adamw's feedback to Manual Partitioning UI
16:43:43 <adamw> well it clearly doesn't HAVE to be, but viking-ice is obviously right that listing it at alpha and beta then changing our minds for final isn't _ideal_
16:43:51 <cmurf> they're all related things
16:44:08 <jreznik> Viking-Ice: Fedora is not RHEL - so we will have different set of features than RHEL as always
16:44:16 <cmurf> And the way I see it, Manual Partitioning should be decoupled from the installer.
16:44:39 <Viking-Ice> jreznik,  Fedora is not RHEL you should explain that to some of your coworkers ;)
16:44:43 <jreznik> adamw: it's for what Alpha/Beta is - to test stuff, ask people to take a look and delist in case it's not there
16:44:47 <cmurf> The sorts of sane things people need to do with Thinp and Btrfs can't be done with the installer now, and yet the UI is too complicated, and there's one guy working on storage stuff.
16:44:59 <cmurf> And a big reason why I think that is, is because the UI is installer context only, not general purpose.
16:45:00 <Viking-Ice> jreznik, but advertizing something then retract that does not work well
16:45:13 <jreznik> Viking-Ice: right, so I don't get you pointing to redhat press release and talking about not ours customer
16:45:15 <jreznik> s
16:45:49 <cmurf> So who would care to contribute much effort to that when it's a.) a RHEL/Fedora only installer and b.) not a GUI that can be used to create storage for use other than for installing an OS.
16:46:27 <cmurf> This also relates to Viking-Ice's email to the anaconda list that went unanswered essentially, which is stabilizing the installer.
16:46:43 <cmurf> I think a huge number of bugs are in custom partitioning compared to any other single area.
16:47:53 <cmurf> Anyway, maybe this actually maybe this needs to be brought to one of the WG's like the workstation WG or something and see if they want to flush this out - as if they don't already have enough to chew on...
16:47:55 <adamw> jreznik: I think viking's point is that press releases put out by RH's press office are fairly widely distributed and read by important folks
16:48:16 <Viking-Ice> adamw, right
16:48:21 <adamw> cmurf: i'm not sure it'd be any single WG's responsibility :/
16:48:36 <Viking-Ice> adamw, specially the cloud section these days
16:48:40 <cmurf> I think server WG could almost care less about this except having kickstart functionality
16:48:43 <adamw> it all depends on how this stuff about whether different products can have different install experiences and schedules and stuff shakes out
16:49:06 <Viking-Ice> adamw, we might be having a competing installer to anaconda
16:49:07 <cmurf> and cloud WG may not care about installer UI at all either as far as I can tell
16:49:17 <Viking-Ice> adamw, sooner rather then later
16:49:20 <jreznik> adamw: but it does not force us to ship something we do not trust to
16:50:41 <cmurf> manual partitioning is simultaneously too complicated and not capable enough...
16:52:15 <Viking-Ice> adamw, I asked the anconda folks the other day about all the customized installer ideas for wg ( because we in serverWG would need custom netinstaller iso ) and they said that would only be limited to custom spokes
16:53:17 <adamw> okay
16:53:20 <cmurf> And on the other hand, it's not fair to always go to anaconda folks and basically say "gimme"
16:53:22 <adamw> so we clearly have a _bigger_ mess here
16:53:46 <adamw> but cmurf's idea about de-emphasizing thinp and btrfs is something we at least have the potential to do for f20 if we think it's the right thing to do
16:54:04 <Viking-Ice> "<mkolman> Viking-Ice: well, I think we could show different spokes based on the WG
16:54:04 <Viking-Ice> Viking-Ice: and if a WG wants some specific functionality, there is the Anaconda addon API they can use to write a custom addon"
16:54:17 <cmurf> adamw: it might be as simple as me not looking for anymore bugs seeing as the vast majority of them are ones i found, filed, and nominated as blockers
16:54:20 <adamw> btrfs i'm not sure about - and it'd be more complex to 'conditionally take out' - but thinp should 'lift out' quite easily, to be made available only with a parameter or only in custom part or something
16:54:35 * kparal is for de-emphasizing btrfs and thinp and rather spending the time on blivet unit testing
16:54:36 <cmurf> if i stop doing that voluntarily, probably 90% of the urgency goes away
16:54:41 <adamw> what do others feel about proposing that thinp be made less prominent?
16:55:12 <Viking-Ice> both brtfs as well as thinp should be in stage of experimental
16:55:20 <Viking-Ice> marketing wize
16:55:36 <Viking-Ice> or feature preview or what they call it these day not ready for production so to speak
16:55:53 <cmurf> well what's funny is that Btrfs developers consider it experimental still, yet it was made an unhidden feature in Fedora circa F16.
16:56:28 <cmurf> And then LVM thinp is kinda sorta considered stable but somehow ended up in the installer without any preview period at all.
16:56:33 <kparal> users should be notified that these two filesystems are experimental and the installation might not proceed smoothly. and we should not take them as blockers\
16:58:10 <cmurf> kparal: for thinp that seems reasonable, for Btrfs that seems like a regression only now that the camel's nose is well inside the tent
16:58:30 <kparal> let's call it a fix :)
16:59:04 <cmurf> I'd call it a policy to explicitly allow kicking Btrfs cans down the road without an actual plan.
16:59:26 <cmurf> I think there should be a plan so we know what sorts of exposure there is, and what to test, etc.
16:59:39 <Viking-Ice> cmurf, right Josef will come and let us know when it's good enough
17:00:27 <cmurf> Btrfs is good enough. The openSUSE folks have a lot of this stuff working in their installer, and they don't have broken kernel updates.
17:01:03 <cmurf> Fedora GRUB2 is behind upstream's Btrfs fixes.
17:01:14 <jreznik> kparal: anaconda guys were more inclined to allow it boot time over that warning
17:01:22 <cmurf> Grubby is confused about Btrfs, not the other way around.
17:01:30 <Viking-Ice> <shrug> we need more/new installer and dev team+
17:02:11 <cmurf> The installer has no idea what to think of 100 snapshots of root, so it shows them as 100 independent installations without any differentiation at all.
17:02:12 <cmurf> Etc.
17:03:13 <Viking-Ice> cmurf, as well as this http://www.spinics.net/lists/linux-btrfs/msg25502.html
17:03:54 <Viking-Ice> which manifests itself like this " is initially mounted readonly by the initramfs, and then after switching
17:03:54 <Viking-Ice> to the real system, /home is attempted to be mounted in parallel with /
17:03:54 <Viking-Ice> being remounted rw. If remounting rw happens first, boot proceeds. If
17:03:54 <Viking-Ice> mounting /home is attempted to realy, it fails."
17:04:49 <Viking-Ice> so there are some issues with dracut/systemd and btrfs snapshots ro/rw
17:04:58 <adamw> so we have kparal's proposal:
17:05:02 <adamw> "users should be notified that these two filesystems are experimental and the installation might not proceed smoothly. and we should not take them as blockers\"
17:05:09 <Viking-Ice> ack
17:05:13 <adamw> do we want to vote on that?
17:05:20 <Viking-Ice> already did ;)
17:05:22 <adamw> =)
17:05:24 <adamw> anyone else?
17:05:26 <kparal> can we, just our team alone?
17:05:27 <roshi> ack
17:05:33 <adamw> kparal: let me clarify:
17:05:35 <cmurf> i agree with the first part, I don't agree with the 2nd
17:05:49 <cmurf> Users should be warned. We should still take Btrfs blockers.
17:06:03 <Viking-Ice> we cannot and should not block on experimental
17:06:07 <jreznik> cmurf: the reason why we do it is to not to block on it
17:06:22 <cmurf> We've been blocking on it for what, 2 years?
17:06:28 <jreznik> otherwise it's nonsense block on something that we consider experimental
17:06:29 <kparal> cmurf: I meant that we might not consider btrfs and thinp to have same weight as ext4, for example
17:06:30 <cmurf> Oh wait, we've been blocking on some bugs, but not other bugs.
17:06:49 <adamw> propose #agreed we will propose to anaconda team and/or fesco that anaconda and F20 marketing be modified to put LVM thinp in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview
17:06:52 <kparal> but we can still take blocker for really important cases
17:06:53 <jreznik> cmurf: and it's something we want to change to lesser overhead with blocking on something we do not think it's there
17:07:02 <adamw> (I'll make an identical separate proposal for btrfs so we can vote on them separately)
17:07:05 <cmurf> Well thinp is a bit out of scope seeing as it's a year old compared to 7 years for Btrfs.
17:07:10 <Viking-Ice> adamw,  just lvm thinp
17:07:18 <adamw> vote on thinp first
17:07:22 <Viking-Ice> ack
17:07:34 <kparal> ack
17:07:36 <adamw> ack for me
17:07:36 <jreznik> ack
17:07:39 <roshi> ack
17:07:42 <mkrizek> ack
17:07:45 <adamw> i think that passes
17:07:46 <cmurf> jreznik: I think we need to differentiate Btrfs problems from other problems.
17:07:48 <tflink> +1 ach
17:07:50 <tflink> ack
17:07:52 <adamw> #agreed we will propose to anaconda team and/or fesco that anaconda and F20 marketing be modified to put LVM thinp in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview
17:08:05 <adamw> so for btrfs do we want to vote on an identical proposal, or take a different approach?
17:08:06 <jreznik> adamw: I'll take care of this as part of thinp change
17:08:21 <adamw> #action jreznik to move forward with proposing switch to 'feature preview mode' for thinp
17:09:03 <adamw> thoughts on btrfs specifically now thinp's out of the way?
17:09:05 <sgallagh> adamw: Please submit it to FESCo if you think we need to invoke the fallback plan
17:09:23 <sgallagh> (Which it sounds like we do)
17:09:24 <cmurf> And btw on thinp, I've yet to see any beta related bugs filed on it. *shrug*
17:09:34 <adamw> sgallagh: deferring to jreznik
17:09:38 <sgallagh> ack
17:10:00 <adamw> sgallagh: the contingency plan is...somewhat sparse: https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport#Contingency_Plan
17:10:09 <sgallagh> cmurf: It didn't work at Alpha, so it probably should have been deferred then
17:10:13 <adamw> so we're sort of inventing one. :)
17:10:39 <cmurf> The issues with thinp are that due to its fixes, conventional LVM seems to have some new bugs that are regressions.
17:10:41 <sgallagh> adamw: Hmm, I could have swarn the contingency plan was "remove it from the drop-down box"
17:10:50 <jreznik> sgallagh: me too
17:11:02 <adamw> welp, yeah, that's more or less what we're suggesting
17:11:06 <sgallagh> jreznik: What are you saying "me too" to?
17:11:18 <adamw> so if we don't have a concrete proposal for btrfs we should probably start wrapping up
17:11:20 <adamw> it's 11 mins over
17:11:23 <jreznik> sgallagh: I thought the same
17:11:43 <kparal> I'd OK with the same proposal for btrfs. of course it's just a proposal and anaconda team's opinion is most important here
17:11:46 <cmurf> adamw: put the question to one of the lists? And then discuss in a week?
17:12:13 <cmurf> Almost any bug at this point is an F21 RFE
17:13:04 <Viking-Ice> so btrfs next?
17:14:02 <adamw> the thing for btrfs is i'm not sure we could cleanly lift it out at this point
17:14:17 <adamw> we could take it out of the installation options drop-down and make it custom only...
17:14:21 <cmurf> I think doing that would be inappropriate anyway.
17:14:30 <adamw> but it actually works fairly well from installation options, so i'm not sure that addresses anything
17:14:40 <cmurf> That's the only one what works reliably.
17:14:43 <cmurf> what=that
17:14:57 <cmurf> All of the problems are Manual Partitioning problems.
17:15:13 <Viking-Ice> adamw,  think of it this way it's a bit worrying in relation with btrfs that harald's patch has been sitting there on their mailing listfor 5 months without a reply.
17:15:24 <cmurf> If I have 1000 snapshots, I can't even use Manual Partitioning to blow away the Btrfs volume.
17:15:33 <cmurf> Guided can do that.
17:15:35 <Viking-Ice> and there are *issues* with btrfs and dracut/systemd/fstab
17:15:36 <jreznik> fesco#1140 reopened for thinp
17:15:39 <jreznik> sgallagh: ^^^
17:15:42 <sgallagh> jreznik: ack
17:15:49 <kparal> cross-ML discussion with anaconda then? /me is hungry
17:16:03 <Viking-Ice> kparal, enough food in the beer ;)
17:16:05 <cmurf> kparal: me too
17:16:33 <cmurf> Tech preview for Btrfs is a hammer. We need a scalpal.
17:17:01 <kparal> Viking-Ice: Czech say that beer is a liquid beer
17:17:02 <adamw> OK, seems like we don't really have a btrfs proposal at present, so let's wind it up
17:17:11 <kparal> er
17:17:12 <adamw> cmurf: you want an action item to try and move it forward?
17:17:24 <kparal> Viking-Ice: beer is a liquid bread :-)
17:17:39 <adamw> kparal: or you? or both of you? :)
17:17:59 <adamw> #action cmurf and kparal to discuss status of btrfs with anaconda team
17:18:00 <adamw> there!
17:18:09 <kparal> hmm
17:18:09 <cmurf> fine
17:18:17 <kparal> whatever, need to eat! :)
17:18:18 <cmurf> and adamw is off the hook haha
17:18:24 <cmurf> clever
17:18:37 <adamw> well hey, i never thought of that!
17:18:39 <adamw> ;)
17:18:43 * adamw sets quantum fuse
17:18:56 <Viking-Ice> hey where is that btrfs proposal ?
17:19:35 <Viking-Ice> just copy paste the previous one
17:19:40 <Viking-Ice> what the hell?
17:20:34 <adamw> Viking-Ice: sorry, it didn't look like it had the votes to go through in the same form
17:20:38 <adamw> but if you want to vote on it, we can
17:20:52 <Viking-Ice> adamw, who's against it ?
17:20:58 <cmurf> i am as written.
17:21:01 <adamw> i am as written too
17:21:11 <Viking-Ice> and me and kparal are both with it
17:21:28 <adamw> propose #agreed we will propose to anaconda team and/or fesco that anaconda and F20 marketing be modified to put btrfs thinp in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview
17:21:29 <kparal> no, I'm for dinner and against everything else
17:21:29 <cmurf> To back out Btrfs that much, that broadly, I think is beyond this venue's voting power.
17:21:32 <adamw> grr
17:21:41 <adamw> propose #agreed we will propose to anaconda team and/or fesco that anaconda and F20 marketing be modified to put btrfs in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview
17:21:58 <cmurf> That needs to go to a WG or FESCO, or at least involve the anaconda team, and Josef or Eric S
17:21:58 <adamw> cmurf: we're not voting to _do_ anything, only to propose it to the people who can do it / require it to be done
17:21:59 <Viking-Ice> ack due to known issues with btrfs/fstab/systemd/dracut
17:22:20 <adamw> nack on the basis that we can't really make that change to btrfs cleanly this late
17:22:21 <Viking-Ice> which upstreams seems to be ignoring or considering features
17:22:26 <adamw> (thinp lifts out much more easily)
17:22:38 <Viking-Ice> adamw, so install broken setup for users great ;)
17:23:07 <cmurf> nack on the proposal
17:23:14 <kparal> I think we should have a longer discussion about the possibilities
17:23:22 <kparal> nack at the moment
17:23:37 <jreznik> agreed
17:23:57 <Viking-Ice> good to know your guys perspective on installing broken setup for our end user base
17:24:08 <cmurf> I just wanted a line in the sand, not 25 dump drunks of sand dropped on Btrfs.
17:24:19 <cmurf> haha drunks = trucks
17:24:20 <Viking-Ice> we could have left FESCO to ack/nack this and take the blame or praise
17:24:34 <adamw> Viking-Ice: you could take it to fesco as a personal proposal if you feel strongly about it
17:24:45 <adamw> but looks like it's not got the votes to be a QA group proposal
17:24:45 <cmurf> Might be interesting to see what happens.
17:24:45 <Viking-Ice> adamw, I said my mind here
17:24:46 * kparal goes afk
17:24:54 <adamw> okay, restarting the quantum fuse!
17:24:56 <cmurf> But that's a lot of rope to hand over to FESCO.
17:24:56 * jreznik has to go now too
17:25:04 <Viking-Ice> I'm not to blame when the raise contions occures for our end users
17:25:19 <cmurf> Viking-Ice: It's not a new problem.
17:25:28 <Viking-Ice> cmurf, really...
17:25:33 <Viking-Ice> then keep tit
17:25:45 <cmurf> charming
17:26:50 <adamw> thanks for coming, folks
17:26:51 <adamw> #endmeeting