17:01:05 #startmeeting FESCO (2012-09-19) 17:01:05 Meeting started Wed Sep 19 17:01:05 2012 UTC. The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:05 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:01:13 #meetingname fesco 17:01:13 The meeting name has been set to 'fesco' 17:01:20 #chair notting nirik mjg59 mmaslano t8m pjones mitr limburgher jwb 17:01:20 Current chairs: jwb limburgher mitr mjg59 mmaslano nirik notting pjones t8m 17:01:27 #topic init process 17:01:30 hello 17:01:31 * nirik is here. 17:01:34 hi 17:01:37 hello 17:01:41 Hello all 17:02:37 * limburgher here 17:03:07 jwb, mjg59, around? 17:03:38 here 17:03:53 will notting attend? 17:04:15 I don't think so. 17:04:43 anyway we can start as we have the quorum 17:05:03 t8m: not based on ticket #951 17:05:05 #topic 932 F18 Features - progress at Feature Freeze 17:05:19 .fesco 932 17:05:22 t8m: #932 (F18 Features - progress at Feature Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/932 17:06:13 not really much in the way of updates that I see. 17:06:17 I just added this to the list of topics if anybody wants to discuss any feature. 17:06:25 * nirik nods. 17:06:39 If nobody speaks up we can move on 17:06:48 we should probibly try and get people to update now that alpha is out and things are flowing into the tree more quickly. 17:07:03 yep 17:07:08 did the 9/26 date move out? 17:07:13 because of the multiple slips? 17:07:23 I think so 17:07:37 should probably update the ticket with whatever that new date is. i'll find out 17:07:41 1 week before "features 100% complete" is oct 2 17:07:42 Thanks 17:07:53 thanks mitr 17:08:12 so our oct 3 meeting then? 17:08:18 yeah 17:08:46 #info As the F18 updates are not frozen anymore after the Alpha release, please finish your incomplete features soon. 17:08:48 Leaving the deadline at oct 2 is better - that gives us at least 1 day to review tem all :) 17:09:07 mitr, +1 17:09:19 yes, +1 17:09:30 i already did that in the ticket 17:09:47 OK anything else? 17:10:15 +1 17:10:18 moving on 17:10:29 #topic 940 The tmp-on-tmpfs feature should be disabled by default 17:10:35 .fesco 940 17:10:38 t8m: #940 (The tmp-on-tmpfs feature should be disabled by default) – FESCo - https://fedorahosted.org/fesco/ticket/940 17:10:58 Discussion here has been. . .warm. 17:11:22 Again I've added this to the agenda if someone was persuaded to change his stance by the recent activity in the ticket. 17:11:30 yeah. I suspect reality is somewhere between the two extremes... 17:11:51 Indeed. No change here. 17:13:14 so, I'm not sure how to come to a nice medium here... the default has to be one way or another. 17:13:31 where were we at vote wise? 17:13:45 keep it unless testing shows numerous problems 17:13:48 nirik, I think me, mitr, mmaslano would vote for revert 17:13:56 nirik, the rest to keep it? 17:14:05 honestly 17:14:07 I think that's about right. 17:14:12 * nirik nods. 17:14:13 the least we should do is keep it until the beta 17:14:15 it's easy to revert 17:14:16 how hard is it to enable it yourself? 17:14:20 and the bugs should be fixed anyway 17:14:21 dead simple 17:14:25 it's way to early to revert this now 17:14:27 and also disable. ;) 17:14:35 i did so on f17 laptop when this got interesting. 17:14:40 no issues to date. 17:14:41 t8m: yeah, that sounds right 17:14:44 +1 anecdote 17:15:02 limburgher: that's unfair because the case where this really hurts is with limited memory VMs 17:15:07 I'm fine either way then. I personally want access to this feature but no biggie if I have to manually enable it 17:15:12 (assuming your laptop doesn't have 512 MB RAM) 17:15:15 is there some way we can default it to off in vms? 17:15:25 so, please do net revert this right now, if you make the decision then please wait until the beta, but there is really no point in reverting this now before we have any serious bug reports coming in 17:15:28 rwmjones: I wasn't using it as an argument, merely a data point. 17:15:35 how about comment 28? 17:15:35 nirik: kickstart. :) 17:15:47 that's a data point -- thousands of potential bugs 17:15:47 rwmjones: while I'm sympathetic to that, it's still very easy to disable in that case. 17:16:08 nirik: yes, that would be asy, we could add a ConditionVirtualization= to the unit. But honestly, I think we totally want this in a VM too 17:16:33 rwmjones: so, all those things write unbounded tmp files... isn't that also a problem on disk /tmp ? just less so? 17:16:41 rwmjones, I completely agree with you, unfortunately it did not persuaded anyone from FESCo to change his stance 17:16:47 pjones: Given the lack of progress on fixing the bugs so far, I'm not very optimistic. Based on comment#28, it would take ~2.5 man-months to only check all packages for issues 17:17:00 /tmp on disk is normally far larger 17:17:18 mitr: honestly I don't really agree with the /assessment/ of the bugs listed in comment#28 17:17:23 and there's a case that if your program really needs gbs of data, then you have to have enough disk space for it 17:17:24 nirik: Arguably runinng out of RAM is much harder to recover from than running out of disk space (and disk space has something reserved for root) 17:17:38 rwmjones, +1 17:17:49 pjones: We can argue about that for hours, sure. But the two man-months is a minimum to get any results. 17:17:51 mitr, +1 17:18:05 mitr: you don't run out of RAM, you'll first hit the tmpfs size limit as configured in the mountoptions 17:18:08 mitr, I thought tmpfs was limited so it can't use all your ram anyway 17:18:12 However, unless there is a radical change in view here... 17:18:24 proposal: Table this until the originally scheduled revisit date. 17:18:31 I agree 17:18:31 mitr, +1 17:18:32 admittedly the overall impact could be running out :) 17:18:37 mitr: +1 17:18:38 yep. 17:18:51 moving on 17:19:01 #topic 951 Co-maintainership of Chitlesh's Fedora packages maintainer issue 17:19:08 .fesco 951 17:19:10 t8m: #951 (Co-maintainership of Chitlesh's Fedora packages) – FESCo - https://fedorahosted.org/fesco/ticket/951 17:19:24 i have no problems with this request 17:19:56 I'm ok with it as well, although they are not as idle has perhaps first indicated. 17:20:18 I agree with nirik. 17:20:26 I'm ok although this request does not fully follow the nonresponsive maintainer policy 17:20:37 No, but then they're not asking for ownership. 17:20:47 Which is good, Chitlesh has been great in the last. 17:20:52 s/last/past/ 17:22:10 I'm not 100% happy with the deviation from the policy, but +1 is the right thing to do here - waiting another 3 weeks would unpleasantly interact with F18 beta schedule 17:22:22 s/but/& I think/ 17:22:30 so If I can count above as voting - that is +5 and with nottings vote in the ticket +6 17:22:38 you can 17:22:40 in my case 17:22:50 I agree with nirik 17:23:53 #agreed Shakthi Kannan is approved as co-maintainer of Chitlesh Goorah's packages 17:24:03 yeah, +1 as well 17:24:15 Who can give him this access? 17:24:21 I can. 17:24:35 It's a long list, but I'll get on it ASAP. 17:24:42 thanks limburgher 17:24:46 np 17:25:24 #action limburgher will add Shakthi Kannan to Chitlesh's packages as comaintainer 17:25:47 #topic Next week chair 17:26:03 anybody wants to be next week chair? 17:26:14 I'm not sure I'll be able to attend 17:26:48 * mmaslano neither 17:26:59 I can if no one else is able. 17:27:07 i'll chair 17:27:20 * nirik is happy to let jwb do it. ;) 17:27:31 #action jwb will chair next week meeting 17:27:46 #topic Open Floor 17:27:59 Anything for Open Floor? 17:29:55 nope 17:30:16 I'll close the meeting in 19:31 then. 17:30:31 (UTC+2 timezone :)) 17:31:07 #endmeeting