17:00:01 #startmeeting FESCO (2012-10-31) 17:00:01 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:01 #meetingname fesco 17:00:01 #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb 17:00:01 #topic init process 17:00:01 The meeting name has been set to 'fesco' 17:00:01 Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m 17:00:07 * limburgher here 17:00:07 i am present 17:00:16 i am here as well 17:00:20 hi 17:00:32 thats 5, so we have quorum. ;) 17:01:01 pjones / mjg59 / t8m / mitr ? 17:01:06 hi 17:02:23 ok, lets go ahead and get started. 17:02:28 #topic #932 F18 Features - progress at Feature Freeze 17:02:28 .fesco 932 17:02:28 https://fedorahosted.org/fesco/ticket/932 17:02:30 nirik: #932 (F18 Features - progress at Features 100% Complete deadline (was: Feature Freeze)) – FESCo - https://fedorahosted.org/fesco/ticket/932 17:02:35 Hello all 17:02:36 Hi 17:02:43 jreznik had an update this morning on the ticket. 17:03:05 * jreznik is ready here 17:03:28 the power features and owncloud postponed to f19 17:03:40 +1 on that. 17:03:58 what exactly is missing in the rngd one? 17:04:15 notting: how to switch it default-on 17:04:25 last time I was talking with jeff 17:05:09 cite: "Just looking for a pointer to the proper systemd switch to make it default-on..." 17:05:35 that's the preset file 17:05:39 that would be a bug against systemd to change it's default on preset? 17:05:48 * pjones is here. 17:05:53 sorry, bit late. 17:05:58 hmm, indeed, it's a preset thing 17:06:18 http://pkgs.fedoraproject.org/cgit/systemd.git/tree/90-default.preset?h=f18 17:06:26 ok, I can point him to presets 17:06:48 we should probably improve our guidelines if it's not obvious 17:08:29 ok, so any objections to the power features and owncloud going to f19? any others we should punt to f19 now? 17:08:37 no 17:08:41 nirik: I already did it 17:08:50 jreznik: great 17:08:57 for power and owncloud 17:09:24 no reply for openshift origin about the current status, so I'm +1 moving to F19 17:09:40 rngd should be still doable and simple one... so not sure 17:09:41 yeah, agreed. i don't think the ruby thing is going to get cleared up in time 17:10:00 yeah, I think I saw in the cloud meeting that they were now going to target f19 17:10:11 ok 17:10:28 " We're going to shoot for Fedora 19 as a feature." 17:10:45 ok 17:11:37 Usermode Migration ? 17:12:05 this is definitely not finished yet 17:12:09 nirik: as notting said, it's more continuous effort, same as sysvtosystemd 17:12:18 and won't be in F18 17:12:50 so the question is how to deal with these long term features, reapprove for every release? 17:13:18 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 I think that's a discussion for the feature process improvement conversation. 17:14:04 nirik: in the usermode migration case, then, it's just move-to-f19 17:14:10 notting: ok 17:14:24 the infrastructure work there, but if the feature is 'migration', basically nothing has been migrated 17:15:05 right, fine with me. 17:16:00 new installer ui is at 80%? 17:16:18 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 nirik: for sysvsystemd I ask Viking-Ice to do it, we were arguing how to solve it :) 17:17:07 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 it isn't ? 17:17:35 what parts of functionality are not yet written and testable? 17:18:03 Iignoring code quality, do we have 100% of expected (by whom?) features, or do we need to release-note dropped functionality? 17:18:05 nirik: if we consider fedup for example as part of rewrite? to have feature parity? 17:18:27 "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 ok, that might be a problem 17:19:29 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 sure, I just don't think 80% is accurate... but nevermind that. 17:19:53 Anything else on this ticket? 17:20:00 shall we close it now? 17:20:21 nirik: ok, I'll work with anaconda on updates 17:20:40 pjones: what about secure boot one? 17:20:46 It's code complete 17:20:59 right now we're waiting on lawyers, with whom we've just had a phone call that was fairly promising 17:21:03 The final signing hasn't been done because we're still blocked on legal agreement 17:21:08 But this week really this time 17:21:23 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 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 pjones: well as it's code complete, it could be probably set to 100% 17:23:14 Viking-Ice: right. update to whats done now, repurpose for f19 to do more. 17:23:27 jreznik: if you want to change the wiki that's fine. 17:23:33 nirik, it's not unlikely that there will be new feature process in f19 ( or at least I hope so ) 17:23:45 Viking-Ice: I think we all do. ;) 17:23:56 (hope it's changed that is) 17:24:06 indeed 17:24:10 anyhow, if no objections, close this ticket and move on to next... 17:24:12 jreznik: *I'm* not going to change the wiki until it actually works. 17:24:19 But it's a wiki. 17:24:36 pjones: fair enough 17:24:48 #topic #960 F18 schedule + the holidays 17:24:48 .fesco 960 17:24:49 https://fedorahosted.org/fesco/ticket/960 17:24:51 nirik: #960 (F18 schedule + the holidays) – FESCo - https://fedorahosted.org/fesco/ticket/960 17:25:09 so, not sure what we want to do here. It seems likely we will slip at least another week. 17:25:22 jreznik: 23th of December? 17:25:23 It does. 17:25:25 or in January? 17:25:26 * nirik finds it hard to discuss abstracts until we know more . 17:25:33 no 17:25:48 current release is scheduled for 2012-12-11 17:25:59 if we slip a week (as seems likely) it will be 2012-12-18 17:26:15 for now, it's still ok but we're going to slip probably one more week... that's 18 17:26:21 right. 17:26:35 so would be great to have at least one spare week to cut off from current schedule 17:26:56 and yeah, latest date this year could be 23, dgilmore seems to be ok with that 17:27:02 jreznik: where do you propose cutting it? 17:27:34 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 one of the weeks after beta release but before final freeze? 17:27:48 nirik: yep 17:27:55 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 t8m: agreed. I don't think anyone is proposing changing release critera tho 17:28:32 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 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 Right now that's seems purely theoretical though. 17:29:31 mitr: yep 17:29:42 I'd like to ask teams on readiness meeting 17:29:55 well, I don't think we can reduce mirroring time any... but thats not super long already. 17:30:09 dgilmore, docs team, commonbug people are ok right now with it 17:30:26 nirik: we need three days 17:30:31 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 nirik: in case we slip now (and probably we will) 17:31:03 jreznik: we currently have 4-5... stage content on friday, release on tuesday. 17:31:08 (s/results/released ISO/ above, the other teams do produce results and I didn't want to imply otherwise) 17:31:15 if that time is reduced, we will have fewer mirrors ready 17:31:46 nirik: that's what dennis told me, it should be enough... 17:31:59 as a real minimum 17:32:20 ok. ;( 17:32:32 * nirik isn't happy with 3 days particularly, but we could try and make it work. 17:32:33 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 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 mitr: I know, I wanted to do so too... but it really depends on what problem we will hit 17:33:35 mitr: right, but at t-1 day, the number of people needed is much smaller 17:33:53 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 notting: indeed, it depends on what issue we will hit... 17:35:01 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 jreznik: well, ideally we do that if we slip a week (which seems pretty likely) 17:35:28 what about - if we slip on Thursday, pull 1 week from schedule/ 17:35:34 right. 17:35:55 and no objections are raised on readiness meeting 17:36:02 +1 17:36:05 (follows go/no-go) 17:36:57 anyone else? I see nirik ok with it, t8m... 17:37:04 +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 nirik: out, and as high-quality as humanly possible. 17:37:25 ok, +1 17:37:31 +1 17:37:51 so, that would mean, slip a week, but keep all milestones after beta release the same right? 17:38:00 +1 17:38:03 +1 17:38:04 nirik: yep 17:39:09 Final Change Deadline would be still Mon 2012-11-26 17:39:10 #agreed if we slip on Thursday, pull 1 week from schedule after beta release but before final freeze 17:39:22 ok, anything else on this? 17:39:44 #topic #961 Clarification request- Is Java (including the JVM) exempt from Multilib 17:39:44 .fesco 961 17:39:44 https://fedorahosted.org/fesco/ticket/961 17:39:46 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 Are there any cases where this actually matters? 17:40:32 I don't know java well enough 17:40:33 so, drop 32bit support? ;) sorry 17:41:01 mjg59: someone manually installing a 32-bit browser and wanting java plugin support, i suppose 17:41:04 So, it seems that this is already the case, and they just want us to note it officially... 17:41:10 notting: Ok 17:41:11 mjg59: Yes, java applications can, and fairly frequently do, include native extensions. I.e. supporting 32-bit-only Java apps. 17:41:14 and fixing it would be 'difficult' 17:41:20 but yes, this is the de-facto policy 17:41:22 Oh, great 17:41:36 I'm glad "Write once, run anywhere" was such a success 17:42:05 So sure, unless we have a good plan for changing practice policies should represent practice 17:42:05 mjg59: The Java standard library just doesn't have enough interfaces to the underlying OS, so... 17:42:06 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 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 I'm +1 17:42:20 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 notting: I really don't know much. 17:42:59 but in any case, i'm +1 to this 17:43:04 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 We (FESCo) really need a page that logs decisions... 17:43:47 +1 java sig knows better than we do 17:43:47 +1 as that's unfortunately the only thing that could be done just now 17:44:00 but this could simply got into the Java part of the packaging guidelines I think. 17:44:03 https://fedoraproject.org/wiki/Category:FESCo_policy 17:44:07 but yeah 17:44:37 ok, thats enough to pass. 17:44:50 #agreed proposal is accepted 17:45:00 #topic #963 change of names of configuration files 17:45:00 .fesco 963 17:45:00 https://fedorahosted.org/fesco/ticket/963 17:45:01 nirik: #963 (change of names of configuration files) – FESCo - https://fedorahosted.org/fesco/ticket/963 17:45:36 so, what do we want to do here. 17:45:41 * nirik thinks what a mess. 17:46:08 It's not like it's hard to check the tree for every package that references these files 17:46:32 mjg59: Right, but someone has to do it. 17:46:35 in mailing thread were mentioned some problems 17:46:45 Right. But that could have been done in the time that thread took. 17:47:00 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 #proposal Tell Kay to check an exploded tree and just fix everything 17:47:28 * nirik agrees with t8m 17:47:30 +1 17:47:44 +1 17:47:45 +1 to mjg proposal 17:48:10 sure, +1 although a full exploded tree is going to be a pile of stuff. 17:48:20 nirik: We've got one internally he can get access to, I think 17:48:26 I'll find out how up to date it is 17:48:28 oh? cool. 17:48:33 and it's always possible to make one, given bandwidth and time 17:48:47 * nirik nods. 17:49:05 thats +4? 17:49:22 notting: ... or closely collocated shell machines, which I think exist 17:49:36 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 notting: Once the new files exist, systemd ignores the old ones AFAICS 17:50:19 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 with the exception of /etc/hostname 17:50:56 +1 17:51:10 notting: I may have misread the code. I did ask in the ticket and got no response... 17:52:10 proposal: Kay (or other provenpackager(s)) should go and fix all the config files to use the new files 17:52:13 so i'm +1 to Fixing Things 17:52:17 is that what we are agreeing to? 17:52:30 nirik: Well I was explicitly saying that Kay should take the lead 17:52:37 ok. 17:52:55 but new files is what we want to fix everything to right? to be consistent? 17:53:00 nirik: provenpackers tent to do nothing 17:53:02 tend 17:53:28 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 yeah, but how many times it happened? 17:53:43 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 mmaslano: We are not proposing a general "everyone go fix it" mandate, but asking a specific person to do it. 17:54:18 proposal: Kay should go and fix all the packages affected to use the new config files. 17:54:22 ^ is that better? 17:54:24 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 nirik: Isn't that exactly what mjg59 proposed above? 17:54:35 nirik: Kay should cause all the affected packages to use the new config files 17:54:46 I don't care whether he does it himself 17:54:48 mitr: I am trying to make it clear for the agreed and ticket. 17:54:54 As long as he makes sure it's done 17:54:54 "fix it" is not clear 17:55:16 nirik: oh, right 17:55:20 well I don't think we're talking about neutering 17:55:22 mitr: aha, didn't see how parse_env_file handled return codes 17:55:22 is this for f18 - as fix things at least for beta would not work... freeze... 17:55:36 "fix it" could also mean back out the change and make everything use the old files. 17:55:46 One way or the other 17:55:49 I suspect I know his preference 17:55:55 right. 17:56:31 jreznik: these changes can be fixed in updates no? or does anaconda need further changes for this? 17:56:54 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 mjg59: Does that involve actually doing the work, or is simply filing bugs against affected packages sufficient? 17:57:12 nirik: and if we hit some bad breakage - there's beta blocker process 17:57:15 gholms: Make it happen 17:57:46 mjg59: One interpretation of that is "I can file bugs and walk away." Hence my question. 17:57:54 That's not an interpretation, no 17:58:00 Alrighty then. 17:58:03 so, Kay should go through all packages using those old configuration files and fix them. Right? 17:58:07 Right 17:58:18 proposal: Kay should make sure all the packages affected to use the new config files. 17:58:26 I can't imagine it taking more than an order of magnitude longer than this conversation has 17:58:30 +1 17:58:35 mmaslano: and/or talk to the package owner and ensure that the owner does it 17:58:37 +1 17:58:50 sure, +1. lets get this done and over with. 17:59:02 +1 17:59:20 +1 (again) 17:59:25 +1 17:59:49 +1. also need relnotes, but it looks like someone took care of that? 17:59:58 #agreed Kay should make sure all the packages affected to use the new config files. 18:00:20 notting: seems so. 18:00:24 ok, moving on... 18:00:26 #topic Daylight savings time change 18:00:33 DST changes in the us this upcoming weekend. 18:00:39 are we sticking to same UTC time? 18:00:44 proposal: get UN to make EU and US coordinate DST schedules. 18:00:49 ha 18:01:00 Heh 18:01:06 notting, +1 are you taking action item to do that ? :D 18:01:18 EU already changed 18:01:20 that would mean noon eastern time? 18:01:28 anyhow, I always forget... shall we just stick to UTC and ignore timezone stupidity 18:01:31 Let's move back an hour so it's just the same as it was before 18:01:44 Then this week is the only bizarro week 18:01:51 EU already changed. If we were going to change it for the gap week, we should have done that /this/ week. 18:01:54 mjg59, I suppose you mean forward an hour? 18:02:00 t8m: Yeah 18:02:06 Fucking timezones, how do they work 18:02:06 +1 then 18:02:14 I would be fine with meeting at six, but it might be problem for you ;-) 18:02:25 Keeping the same UTC time means I miss lunch 18:02:28 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 Can I abstain in a way that removes me from the quorum? 18:02:53 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 proposal: Move ahead to 18UTC starting next week. Those people who's lunch are affected update the wiki. ;) 18:03:33 :) 18:03:53 nirik: +1 to having something written down 18:04:14 +1 18:04:26 * nirik is +1 for his own proposal of course. 18:04:35 * limburgher back. FInally. 18:04:41 +1 18:04:43 Ugh. 18:04:45 +1 18:04:54 +1 18:05:06 #agreed Move ahead to 18UTC starting next week. Those people who's lunch are affected update the wiki. ;) 18:05:12 #topic Chair next week 18:05:16 who wants it? 18:05:28 I can do it 18:05:37 thanks. 18:05:45 #action t8m to chair next weeks meeting 18:05:50 #topic Open Floor 18:05:58 anyone have anything for open floor? 18:06:00 Did we skip the LVM one on the basis of the votes in the ticket? 18:06:29 mjg59: yes, it passed in ticket to revert back to lvm by default. 18:06:30 well it had +5 votes 18:06:35 Sure 18:06:41 I wonder if anaconda people read the ticket 18:06:45 which we should make sure and communicate to anaconda folks 18:07:08 pjones is *a* anaconda/anaconda-related person, and is on fesco. so.... 18:07:15 I'm not entirely happy with this being done without actual discussion of the impact of LVM on our users 18:07:15 but yes, explicit communication better than implicit 18:07:27 But the same probably applies to the original change 18:07:27 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 mjg59: yep, the original was not discussed at all too... 18:08:13 So we should plausibly aim to have an actual discussion about that for f19 18:08:20 mjg59: I agree. 18:08:30 also with btrfs in the mix to see if thats finally ready or not 18:08:39 There is some promising LVM-based work coming, and it'd be good to know how that can be integrated 18:08:44 nobody will be making btrfs the default without discussion. 18:08:52 * nirik nods. 18:09:16 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 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 mitr: Interoperability is the main one 18:09:35 jreznik: Is a slip caused entirely by LVM a real threat? 18:09:43 mitr: I doubt it 18:09:50 In any case, I'm strongly against changing the default after beta 18:09:54 adamw: Some LVM-by-default testing had been done, right? 18:10:03 mjg59: yes. 18:10:11 adamw: Would you feel comfortable with it being changed pre-beta? 18:10:50 mjg59: see comments on ticket. 18:10:57 mitr: as we do not have RC and it's Wed today... 18:10:59 no 18:10:59 mjg59: huh? oh. we've actually already moved on the basis that fesco had voted to make the change for beta. 18:11:24 i marked the bug as acceptednth and anaconda team is pulling the fix into 18.22. 18:11:26 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 adamw: Ok 18:12:12 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 adamw: Well that certainly answers my question :) 18:12:15 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 ok, any more open floor stuff? 18:12:59 jwb thought this was open floor time? 18:13:22 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 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 ok, if nothing else, will close out in a minute... 18:15:37 ok, thanks for coming everyone! 18:15:39 #endmeeting