17:00:01 <nirik> #startmeeting FESCO (2012-10-31)
17:00:01 <zodbot> Meeting started Wed Oct 31 17:00:01 2012 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:01 <nirik> #meetingname fesco
17:00:01 <nirik> #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb
17:00:01 <nirik> #topic init process
17:00:01 <zodbot> The meeting name has been set to 'fesco'
17:00:01 <zodbot> Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m
17:00:07 * limburgher here
17:00:07 <jwb> i am present
17:00:16 <notting> i am here as well
17:00:20 <mmaslano> hi
17:00:32 <nirik> thats 5, so we have quorum. ;)
17:01:01 <nirik> pjones / mjg59 / t8m / mitr ?
17:01:06 <t8m> hi
17:02:23 <nirik> ok, lets go ahead and get started.
17:02:28 <nirik> #topic #932 F18 Features - progress at Feature Freeze
17:02:28 <nirik> .fesco 932
17:02:28 <nirik> https://fedorahosted.org/fesco/ticket/932
17:02:30 <zodbot> nirik: #932 (F18 Features - progress at Features 100% Complete deadline (was: Feature Freeze)) – FESCo - https://fedorahosted.org/fesco/ticket/932
17:02:35 <mitr> Hello all
17:02:36 <mjg59> Hi
17:02:43 <nirik> jreznik had an update this morning on the ticket.
17:03:05 * jreznik is ready here
17:03:28 <jreznik> the power features and owncloud postponed to f19
17:03:40 <nirik> +1 on that.
17:03:58 <notting> what exactly is missing in the rngd one?
17:04:15 <jreznik> notting: how to switch it default-on
17:04:25 <jreznik> last time I was talking with jeff
17:05:09 <jreznik> cite: "Just looking for a pointer to the proper systemd switch to make it default-on..."
17:05:35 <notting> that's the preset file
17:05:39 <nirik> that would be a bug against systemd to change it's default on preset?
17:05:48 * pjones is here.
17:05:53 <pjones> sorry, bit late.
17:05:58 <jreznik> hmm, indeed, it's a preset thing
17:06:18 <nirik> http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset?h=f18
17:06:26 <jreznik> ok, I can point him to presets
17:06:48 <mmaslano> we should probably improve our guidelines if it's not obvious
17:08:29 <nirik> ok, so any objections to the power features and owncloud going to f19? any others we should punt to f19 now?
17:08:37 <jwb> no
17:08:41 <jreznik> nirik: I already did it
17:08:50 <nirik> jreznik: great
17:08:57 <jreznik> for power and owncloud
17:09:24 <jreznik> no reply for openshift origin about the current status, so I'm +1 moving to F19
17:09:40 <jreznik> rngd should be still doable and simple one... so not sure
17:09:41 <jwb> yeah, agreed.  i don't think the ruby thing is going to get cleared up in time
17:10:00 <nirik> yeah, I think I saw in the cloud meeting that they were now going to target f19
17:10:11 <jreznik> ok
17:10:28 <nirik> "<tdawson> We're going to shoot for Fedora 19 as a feature."
17:10:45 <mmaslano> ok
17:11:37 <nirik> Usermode Migration ?
17:12:05 <t8m> this is definitely not finished yet
17:12:09 <jreznik> nirik: as notting said, it's more continuous effort, same as sysvtosystemd
17:12:18 <t8m> and won't be in F18
17:12:50 <jreznik> so the question is how to deal with these long term features, reapprove for every release?
17:13:18 <nirik> jreznik: they should change the feature to match whats done NOW and put it to 100% and then redo a feature next release with what they are going to do then'
17:13:26 <limburgher> I think that's a discussion for the feature process improvement conversation.
17:14:04 <notting> nirik: in the usermode migration case, then, it's just move-to-f19
17:14:10 <jreznik> notting: ok
17:14:24 <notting> the infrastructure work there, but if the feature is 'migration', basically nothing has been migrated
17:15:05 <nirik> right, fine with me.
17:16:00 <nirik> new installer ui is at 80%?
17:16:18 <mitr> jreznik: Long-term I think we do need to develop a process for "everyone fix your own packages NOW or else" - but that's a completely separate discussion
17:16:20 <jreznik> nirik: for sysvsystemd I ask Viking-Ice to do it, we were arguing how to solve it :)
17:17:07 <jreznik> nirik: new installer ui - we should be tracking it and it's definitely not 100% now and it would be foolish to ask anaconda to say it's 100% done
17:17:18 <nirik> it isn't ?
17:17:35 <nirik> what parts of functionality are not yet written and testable?
17:18:03 <mitr> Iignoring code quality, do we have 100% of expected (by whom?) features, or do we need to release-note dropped functionality?
17:18:05 <jreznik> nirik: if we consider fedup for example as part of rewrite? to have feature parity?
17:18:27 <nirik> "At the Beta Change Deadline new features must be code complete meaning that all the code required to enable to the new feature is finished."
17:19:25 <mmaslano> ok, that might be a problem
17:19:29 <jreznik> nirik: and we are tracking it in https://fedorahosted.org/fesco/ticket/946 aren't we? as it's a different feature to the rest...
17:19:53 <nirik> sure, I just don't think 80% is accurate... but nevermind that.
17:19:53 <nirik> Anything else on this ticket?
17:20:00 <nirik> shall we close it now?
17:20:21 <jreznik> nirik: ok, I'll work with anaconda on updates
17:20:40 <jreznik> pjones: what about secure boot one?
17:20:46 <mjg59> It's code complete
17:20:59 <pjones> right now we're waiting on lawyers, with whom we've just had a phone call that was fairly promising
17:21:03 <mjg59> The final signing hasn't been done because we're still blocked on legal agreement
17:21:08 <mjg59> But this week really this time
17:21:23 <pjones> we need to do a couple of builds of the three packages in question and then get one signed (which will actually wind up being a 4th package)
17:21:39 * nirik doesn't see any other sub 100% ones to deal with off hand.
17:22:48 <Viking-Ice> nirik we just keep doing the same with sysvtosystemd feature as we did previously release cycle
17:22:55 * nirik listens to the crickets
17:23:02 <jreznik> pjones: well as it's code complete, it could be probably set to 100%
17:23:14 <nirik> Viking-Ice: right. update to whats done now, repurpose for f19 to do more.
17:23:27 <pjones> jreznik: if you want to change the wiki that's fine.
17:23:33 <Viking-Ice> nirik, it's not unlikely that there will be new feature process in f19 ( or at least I hope so )
17:23:45 <nirik> Viking-Ice: I think we all do. ;)
17:23:56 <nirik> (hope it's changed that is)
17:24:06 <limburgher> indeed
17:24:10 <nirik> anyhow, if no objections, close this ticket and move on to next...
17:24:12 <pjones> jreznik: *I'm* not going to change the wiki until it actually works.
17:24:19 <pjones> But it's a wiki.
17:24:36 <jreznik> pjones: fair enough
17:24:48 <nirik> #topic #960 F18 schedule + the holidays
17:24:48 <nirik> .fesco 960
17:24:49 <nirik> https://fedorahosted.org/fesco/ticket/960
17:24:51 <zodbot> nirik: #960 (F18 schedule + the holidays) – FESCo - https://fedorahosted.org/fesco/ticket/960
17:25:09 <nirik> so, not sure what we want to do here. It seems likely we will slip at least another week.
17:25:22 <mmaslano> jreznik: 23th of December?
17:25:23 <limburgher> It does.
17:25:25 <mmaslano> or in January?
17:25:26 * nirik finds it hard to discuss abstracts until we know more .
17:25:33 <nirik> no
17:25:48 <nirik> current release is scheduled for 2012-12-11
17:25:59 <nirik> if we slip a week (as seems likely) it will be 2012-12-18
17:26:15 <jreznik> for now, it's still ok but we're going to slip probably one more week... that's 18
17:26:21 <nirik> right.
17:26:35 <jreznik> so would be great to have at least one spare week to cut off from current schedule
17:26:56 <jreznik> and yeah, latest date this year could be 23, dgilmore seems to be ok with that
17:27:02 <nirik> jreznik: where do you propose cutting it?
17:27:34 <t8m> I'd rather like to see a nice Fedora 18 release some time in 2013 than buggy and ugly Fedora 18 release in 2012.
17:27:41 <nirik> one of the weeks after beta release but before final freeze?
17:27:48 <jreznik> nirik: yep
17:27:55 <notting> so, we essentially have 2 'weeks' of wiggle room in the current process, one of which we're likely to take RSN
17:28:01 <nirik> t8m: agreed. I don't think anyone is proposing changing release critera tho
17:28:32 <mitr> t8m: right, but a part of the release process is indepenent on results quality.  We can have a golden image and continue work on improving the website in the week it takes to mirror and prepare the GA.
17:29:02 <mitr> So _if_ the critical path on the schedule was websites or something else not related to anaconda, there might be a wiggle room.
17:29:27 <mitr> Right now that's seems purely theoretical though.
17:29:31 <jreznik> mitr: yep
17:29:42 <jreznik> I'd like to ask teams on readiness meeting
17:29:55 <nirik> well, I don't think we can reduce mirroring time any... but thats not super long already.
17:30:09 <jreznik> dgilmore, docs team, commonbug people are ok right now with it
17:30:26 <jreznik> nirik: we need three days
17:30:31 <nirik> I'd be ok with pulling a week out of the time between beta release and before final freeze. Other than that, I don't see much place for getting back a week
17:30:52 <jreznik> nirik: in case we slip now (and probably we will)
17:31:03 <nirik> jreznik: we currently have 4-5... stage content on friday, release on tuesday.
17:31:08 <mitr> (s/results/released ISO/ above, the other teams do produce results and I didn't want to imply otherwise)
17:31:15 <nirik> if that time is reduced, we will have fewer mirrors ready
17:31:46 <jreznik> nirik: that's what dennis told me, it should be enough...
17:31:59 <jreznik> as a real minimum
17:32:20 <nirik> ok. ;(
17:32:32 * nirik isn't happy with 3 days particularly, but we could try and make it work.
17:32:33 <mitr> FWIW aiming at the 23rd sounds like a challenge in any case - I'd expect quite a few people, at least in Europe, to take the whole week starting with 22nd off.
17:33:12 <nirik> anyhow, we can: a) do nothing and revisit this next week, b) pull 1 week from the schedule now between beta/final freeze c) something else?
17:33:14 <jreznik> mitr: I know, I wanted to do so too... but it really depends on what problem we will hit
17:33:35 <notting> mitr: right, but at t-1 day, the number of people needed is much smaller
17:33:53 <jreznik> nirik: let's do a) and revisit if we slip... and I'll ask on Thursday readiness meeting if this will work for the rest of folks
17:34:03 * nirik is fine with that.
17:34:19 <jreznik> notting: indeed, it depends on what issue we will hit...
17:35:01 <jreznik> nirik: on the other hand it will look silly to move schedule back if we slip, so b) could be a good idea too
17:35:23 <nirik> jreznik: well, ideally we do that if we slip a week (which seems pretty likely)
17:35:28 <jreznik> what about - if we slip on Thursday, pull 1 week from schedule/
17:35:34 <nirik> right.
17:35:55 <jreznik> and no objections are raised on readiness meeting
17:36:02 <t8m> +1
17:36:05 <jreznik> (follows go/no-go)
17:36:57 <jreznik> anyone else? I see nirik ok with it, t8m...
17:37:04 <limburgher> +1
17:37:05 * nirik is +1 as well, it means less non freeze time for developers, but I think at this point we all just want to get f18 out.
17:37:23 <limburgher> nirik: out, and as high-quality as humanly possible.
17:37:25 <notting> ok, +1
17:37:31 <mmaslano> +1
17:37:51 <nirik> so, that would mean, slip a week, but keep all milestones after beta release the same right?
17:38:00 <mjg59> +1
17:38:03 <jwb> +1
17:38:04 <jreznik> nirik: yep
17:39:09 <jreznik> Final Change Deadline would be still Mon 2012-11-26
17:39:10 <nirik> #agreed  if we slip on Thursday, pull 1 week from schedule after beta release but before final freeze
17:39:22 <nirik> ok, anything else on this?
17:39:44 <nirik> #topic #961 Clarification request- Is Java (including the JVM) exempt from Multilib
17:39:44 <nirik> .fesco 961
17:39:44 <nirik> https://fedorahosted.org/fesco/ticket/961
17:39:46 <zodbot> nirik: #961 (Clarification request- Is Java (including the JVM) exempt from Multilib) – FESCo - https://fedorahosted.org/fesco/ticket/961
17:40:27 * limburgher steps away briefly
17:40:27 <mjg59> Are there any cases where this actually matters?
17:40:32 <mjg59> I don't know java well enough
17:40:33 <nirik> so, drop 32bit support? ;) sorry
17:41:01 <notting> mjg59: someone manually installing a 32-bit browser and wanting java plugin support, i suppose
17:41:04 <nirik> So, it seems that this is already the case, and they just want us to note it officially...
17:41:10 <mjg59> notting: Ok
17:41:11 <mitr> mjg59: Yes, java applications can, and fairly frequently do, include native extensions.  I.e. supporting 32-bit-only Java apps.
17:41:14 <nirik> and fixing it would be 'difficult'
17:41:20 <notting> but yes, this is the de-facto policy
17:41:22 <mjg59> Oh, great
17:41:36 <mjg59> I'm glad "Write once, run anywhere" was such a success
17:42:05 <mjg59> So sure, unless we have a good plan for changing practice policies should represent practice
17:42:05 <mitr> mjg59: The Java standard library just doesn't have enough interfaces to the underlying OS, so...
17:42:06 <nirik> on the one hand, I feel for them... on the other hand, how come they get to ignore the horror of multilib and others don't. ;)
17:42:16 <notting> mitr: i may be misremembering, but where i usually hit those is web apps that see 'linux' in browser string, and just hand you 32-bit x86 linux jni libraries on the assumption that all linux is 32-bit x86?
17:42:19 <mjg59> I'm +1
17:42:20 <mitr> Based on https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate#Notes_on_multiarch , the only solution would basically to turn all .noarch into arch rpms
17:42:23 * jwb steps away for a few min
17:42:50 <mitr> notting: I really don't know much.
17:42:59 <notting> but in any case, i'm +1 to this
17:43:04 <mitr> Just based on the link above, +1
17:43:06 * nirik is a reluctant +1, not sure where to document really tho.
17:43:39 <mitr> We (FESCo) really need a page that logs decisions...
17:43:47 <mmaslano> +1 java sig knows better than we do
17:43:47 <t8m> +1 as that's unfortunately the only thing that could be done just now
17:44:00 <mitr> but this could simply got into the Java part of the packaging guidelines I think.
17:44:03 <nirik> https://fedoraproject.org/wiki/Category:FESCo_policy
17:44:07 <nirik> but yeah
17:44:37 <nirik> ok, thats enough to pass.
17:44:50 <nirik> #agreed proposal is accepted
17:45:00 <nirik> #topic #963 change of names of configuration files
17:45:00 <nirik> .fesco 963
17:45:00 <nirik> https://fedorahosted.org/fesco/ticket/963
17:45:01 <zodbot> nirik: #963 (change of names of configuration files) – FESCo - https://fedorahosted.org/fesco/ticket/963
17:45:36 <nirik> so, what do we want to do here.
17:45:41 * nirik thinks what a mess.
17:46:08 <mjg59> It's not like it's hard to check the tree for every package that references these files
17:46:32 <mitr> mjg59: Right, but someone has to do it.
17:46:35 <mmaslano> in mailing thread were mentioned some problems
17:46:45 <mjg59> Right. But that could have been done in the time that thread took.
17:47:00 <mitr> mmaslano: that particular mail referenced prefdm which is removed in f18
17:47:06 * t8m thinks that people who introduce such changes should do that work.
17:47:11 <mjg59> #proposal Tell Kay to check an exploded tree and just fix everything
17:47:28 * nirik agrees with t8m
17:47:30 <mitr> +1
17:47:44 <t8m> +1
17:47:45 <mmaslano> +1 to mjg proposal
17:48:10 <nirik> sure, +1 although a full exploded tree is going to be a pile of stuff.
17:48:20 <mjg59> nirik: We've got one internally he can get access to, I think
17:48:26 <mjg59> I'll find out how up to date it is
17:48:28 <nirik> oh? cool.
17:48:33 <notting> and it's always possible to make one, given bandwidth and time
17:48:47 * nirik nods.
17:49:05 <nirik> thats +4?
17:49:22 <mitr> notting: ... or closely collocated shell machines, which I think exist
17:49:36 <notting> i'm not up on the devel@ list thread ... this is definitely a problem. i'd be ok with just going through and fixing everything. I believe that even once we do so, manual modification of the old files should still work, if the admin has scripts that do that
17:49:58 <mitr> notting: Once the new files exist, systemd ignores the old ones AFAICS
17:50:19 <notting> mitr: the last time i looked at the code, the old files were read in preference to the new ones on startup
17:50:37 <notting> with the exception of /etc/hostname
17:50:56 <jwb> +1
17:51:10 <mitr> notting: I may have misread the code.  I did ask in the ticket and got no response...
17:52:10 <nirik> proposal:  Kay (or other provenpackager(s)) should go and fix all the config files to use the new files
17:52:13 <notting> so i'm +1 to Fixing Things
17:52:17 <nirik> is that what we are agreeing to?
17:52:30 <mjg59> nirik: Well I was explicitly saying that Kay should take the lead
17:52:37 <nirik> ok.
17:52:55 <nirik> but new files is what we want to fix everything to right? to be consistent?
17:53:00 <mmaslano> nirik: provenpackers tent to do nothing
17:53:02 <mmaslano> tend
17:53:28 <nirik> we can't force them to, but if someone stepped up and said they would do it, wouldn't that be ok?
17:53:41 <mmaslano> yeah, but how many times it happened?
17:53:43 <mitr> notting: in http://cgit.freedesktop.org/systemd/systemd/tree/src/core/locale-setup.c?id=cae356ad49b505a5172d4dbb830d7ec8f32a9953, parse_env_file returns >0 if the file contains something; locale.conf goes first, and that causes the other files to be ignored.
17:54:06 <mitr> mmaslano: We are not proposing a general "everyone go fix it" mandate, but asking a specific person to do it.
17:54:18 <nirik> proposal:  Kay should go and fix all the packages affected to use the new config files.
17:54:22 <nirik> ^ is that better?
17:54:24 <Viking-Ice> just pointing out that deleting the old file ( once migrated ) is the right thing to do to avoid confusion among users and quickly identify problems ( from my pov )
17:54:34 <mitr> nirik: Isn't that exactly what mjg59 proposed above?
17:54:35 <mjg59> nirik: Kay should cause all the affected packages to use the new config files
17:54:46 <mjg59> I don't care whether he does it himself
17:54:48 <nirik> mitr: I am trying to make it clear for the agreed and ticket.
17:54:54 <mjg59> As long as he makes sure it's done
17:54:54 <nirik> "fix it" is not clear
17:55:16 <mitr> nirik: oh, right
17:55:20 <mjg59> well I don't think we're talking about neutering
17:55:22 <notting> mitr: aha, didn't see how parse_env_file handled return codes
17:55:22 <jreznik> is this for f18 - as fix things at least for beta would not work... freeze...
17:55:36 <nirik> "fix it" could also mean back out the change and make everything use the old files.
17:55:46 <mjg59> One way or the other
17:55:49 <mjg59> I suspect I know his preference
17:55:55 <nirik> right.
17:56:31 <nirik> jreznik: these changes can be fixed in updates no? or does anaconda need further changes for this?
17:56:54 <notting> jreznik: the problem is 1) we have this file confusion since f-16 2) with anaconda currently writing both files, it's currently *worse* (AIUI), so we should do Something to make things consistent. at least, as i understand it
17:57:07 <gholms> mjg59: Does that involve actually doing the work, or is simply filing bugs against affected packages sufficient?
17:57:12 <jreznik> nirik: and if we hit some bad breakage - there's beta blocker process
17:57:15 <mjg59> gholms: Make it happen
17:57:46 <gholms> mjg59: One interpretation of that is "I can file bugs and walk away."  Hence my question.
17:57:54 <mjg59> That's not an interpretation, no
17:58:00 <gholms> Alrighty then.
17:58:03 <mmaslano> so, Kay should go through all packages using those old configuration files and fix them. Right?
17:58:07 <mjg59> Right
17:58:18 <nirik> proposal:  Kay should make sure all the packages affected to use the new config files.
17:58:26 <mjg59> I can't imagine it taking more than an order of magnitude longer than this conversation has
17:58:30 <mjg59> +1
17:58:35 <mitr> mmaslano: and/or talk to the package owner and ensure that the owner does it
17:58:37 <mitr> +1
17:58:50 <nirik> sure, +1. lets get this done and over with.
17:59:02 <t8m> +1
17:59:20 <jwb> +1 (again)
17:59:25 <mmaslano> +1
17:59:49 <notting> +1. also need relnotes, but it looks like someone took care of that?
17:59:58 <nirik> #agreed Kay should make sure all the packages affected to use the new config files.
18:00:20 <nirik> notting: seems so.
18:00:24 <nirik> ok, moving on...
18:00:26 <nirik> #topic Daylight savings time change
18:00:33 <nirik> DST changes in the us this upcoming weekend.
18:00:39 <nirik> are we sticking to same UTC time?
18:00:44 <notting> proposal: get UN to make EU and US coordinate DST schedules.
18:00:49 <nirik> ha
18:01:00 <gholms> Heh
18:01:06 <t8m> notting, +1 are you taking action item to do that ? :D
18:01:18 <mjg59> EU already changed
18:01:20 <jwb> that would mean noon eastern time?
18:01:28 <nirik> anyhow, I always forget... shall we just stick to UTC and ignore timezone stupidity
18:01:31 <mjg59> Let's move back an hour so it's just the same as it was before
18:01:44 <mjg59> Then this week is the only bizarro week
18:01:51 <pjones> EU already changed.  If we were going to change it for the gap week, we should have done that /this/ week.
18:01:54 <t8m> mjg59, I suppose you mean forward an hour?
18:02:00 <mjg59> t8m: Yeah
18:02:06 <mjg59> Fucking timezones, how do they work
18:02:06 <t8m> +1 then
18:02:14 <mmaslano> I would be fine with meeting at six, but it might be problem for you ;-)
18:02:25 <mjg59> Keeping the same UTC time means I miss lunch
18:02:28 <mjg59> And then I'll be cranky
18:02:30 * pjones +1 to moving it with the DST change.
18:02:40 * mitr doesn't care about moving at all
18:02:52 <mitr> Can I abstain in a way that removes me from the quorum?
18:02:53 <nirik> I only care in that we need to then change all the wiki pages, etc. ;)
18:02:57 * notting says... pick something.
18:03:25 <nirik> proposal: Move ahead to 18UTC starting next week. Those people who's lunch are affected update the wiki. ;)
18:03:33 <mitr> :)
18:03:53 <notting> nirik: +1 to having something written down
18:04:14 <mmaslano> +1
18:04:26 * nirik is +1 for his own proposal of course.
18:04:35 * limburgher back.  FInally.
18:04:41 <mjg59> +1
18:04:43 <limburgher> Ugh.
18:04:45 <t8m> +1
18:04:54 <limburgher> +1
18:05:06 <nirik> #agreed Move ahead to 18UTC starting next week. Those people who's lunch are affected update the wiki. ;)
18:05:12 <nirik> #topic Chair next week
18:05:16 <nirik> who wants it?
18:05:28 <t8m> I can do it
18:05:37 <nirik> thanks.
18:05:45 <nirik> #action t8m to chair next weeks meeting
18:05:50 <nirik> #topic Open Floor
18:05:58 <nirik> anyone have anything for open floor?
18:06:00 <mjg59> Did we skip the LVM one on the basis of the votes in the ticket?
18:06:29 <nirik> mjg59: yes, it passed in ticket to revert back to lvm by default.
18:06:30 <mmaslano> well it had +5 votes
18:06:35 <mjg59> Sure
18:06:41 <mmaslano> I wonder if anaconda people read the ticket
18:06:45 <nirik> which we should make sure and communicate to anaconda folks
18:07:08 <notting> pjones is *a* anaconda/anaconda-related person, and is on fesco. so....
18:07:15 <mjg59> I'm not entirely happy with this being done without actual discussion of the impact of LVM on our users
18:07:15 <notting> but yes, explicit communication better than implicit
18:07:27 <mjg59> But the same probably applies to the original change
18:07:27 <jreznik> it's more question - do fesco wants it in beta even we would not slip this Thursday? as it would lead to the slip again
18:07:55 <jreznik> mjg59: yep, the original was not discussed at all too...
18:08:13 <mjg59> So we should plausibly aim to have an actual discussion about that for f19
18:08:20 <nirik> mjg59: I agree.
18:08:30 <nirik> also with btrfs in the mix to see if thats finally ready or not
18:08:39 <mjg59> There is some promising LVM-based work coming, and it'd be good to know how that can be integrated
18:08:44 <jwb> nobody will be making btrfs the default without discussion.
18:08:52 * nirik nods.
18:09:16 <nirik> also, it's worth noting that all of this is 'defaults', you can choose something else if you really love it better.
18:09:19 <mitr> mjg59: I haven't seen any noted impact (one suggestion of performace problems), beyond problems with rescuing the system but the anaconda boot.iso "should" usually take care of it.
18:09:32 <mjg59> mitr: Interoperability is the main one
18:09:35 <mitr> jreznik: Is a slip caused entirely by LVM a real threat?
18:09:43 <nirik> mitr: I doubt it
18:09:50 <mitr> In any case, I'm strongly against changing the default after beta
18:09:54 <mjg59> adamw: Some LVM-by-default testing had been done, right?
18:10:03 <nirik> mjg59: yes.
18:10:11 <mjg59> adamw: Would you feel comfortable with it being changed pre-beta?
18:10:50 <nirik> mjg59: see comments on ticket.
18:10:57 <jreznik> mitr: as we do not have RC and it's Wed today...
18:10:59 <jreznik> no
18:10:59 <adamw> mjg59: huh? oh. we've actually already moved on the basis that fesco had voted to make the change for beta.
18:11:24 <adamw> i marked the bug as acceptednth and anaconda team is pulling the fix into 18.22.
18:11:26 <Viking-Ice> I would very much like for fesco to considered giving us in QA 2 whole development cycle to test btrfs before making it the default so we could work in advantage and try to have the transition as smooth as possible as in do target testing documentation writing what not in F19 and make the switch in F20
18:11:54 <mjg59> adamw: Ok
18:12:12 <nirik> Viking-Ice: sure, as far as I know no one has yet formally asked for btrfs by default... but that would be a good thing to talk about them with for sure.
18:12:13 <mjg59> adamw: Well that certainly answers my question :)
18:12:15 <jwb> Viking-Ice, make a note of that on the feature when it's filed.  or open a ticket.  different meeting at the very least
18:12:31 <nirik> ok, any more open floor stuff?
18:12:59 <Viking-Ice> jwb thought this was open floor time?
18:13:22 <mitr> Viking-Ice: The Fedora space has been _very_ quiet about btrfs status for some time...which makes things difficult to judge - in itself a reason to be in favor to your request.
18:13:31 <jwb> Viking-Ice, sure.  we've noted what you requested and i just suggested how you can accomplish that.  i don't think "open floor" means "discuss things taht aren't even proposed"
18:13:52 * mmaslano needs to go home. Bye
18:14:17 * nirik has been leary of btrfs since his last dataloss incident... but that was a year or more ago, so hopefully things are better now.
18:14:52 <nirik> ok, if nothing else, will close out in a minute...
18:15:37 <nirik> ok, thanks for coming everyone!
18:15:39 <nirik> #endmeeting