18:30:18 #startmeeting FESCO (2010-12-01) 18:30:18 Meeting started Wed Dec 1 18:30:18 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:30:18 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:30:18 #meetingname fesco 18:30:18 The meeting name has been set to 'fesco' 18:30:18 #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 marcela 18:30:18 #topic init process 18:30:18 Current chairs: SMParrish ajax cwickert kylem marcela mclasen mjg59 nirik notting 18:30:42 * notting is here 18:30:51 Hi 18:30:57 * pjones is here unnecessarily. 18:31:06 #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 18:31:06 Current chairs: SMParrish ajax cwickert kylem marcela mclasen mjg59 mmaslano nirik notting 18:31:16 pjones: Thanks for your service, you can leave now 18:31:33 A token gift will be provided by mail 18:31:34 woohoo! 18:31:46 ah, I got the nick marcela from fas... sorry about that. 18:32:04 #info SMParrish and mclasen unable to attend today. 18:32:05 hello, I change to mmaslano to be consistent with FAS account 18:32:37 mmaslano: makes sense. ;) welcome. 18:32:44 mmaslano: Hi! 18:34:04 * nirik looks to see if we have quorum... 18:34:19 i'm here, i suppose 18:34:31 ajax, notting, me, you, mmaslano 18:34:34 ok. I think thats 5... 18:34:37 cwickert and kyle appear to be missing 18:35:08 yep. ok, lets go ahead and get started. Will do some new business first... 18:35:11 #topic Welcome new members, Thank departing members. 18:35:27 Welcome mmaslano and thanks to pjones 18:35:57 hello again 18:36:06 I think I have adjusted the approprate wiki pages and trac/mailing lists stuff. 18:36:14 If there is anything I missed, please feel free to let me know. 18:36:49 great 18:37:22 #topic Elect Chair 18:37:41 I'm willing to keep chairing... but if someone else wants it thats ok with me too. ;) 18:37:52 i want to not. 18:38:26 anyone else? 18:38:44 * notting +1s nirik 18:38:59 likewise +1 nirik 18:39:07 nirik: The problem is that you keep doing a good job 18:39:30 * nirik resolves to slack more so he can get replaced. ;) 18:40:28 #info nirik will keep chairing for now. 18:40:34 #topic Meeting time 18:40:43 ok, do we wish to revisit the meeting time again? 18:41:05 I'd like to have it earlier 18:41:19 my availability hasn't changed and is still pretty flexible 18:41:31 Guess we can go through the availability grid again 18:41:54 ok, would someone be willing to file a ticket and provide a whenisgood or the like? 18:42:02 Sure 18:42:31 (a ticket just for tracking it/nagging everyone to fill it out) 18:42:37 mjg59: great. 18:42:50 #action mjg59 to fill out a ticket and whenisgood for us to fill in. 18:43:05 shall we revisit next week at this time then? or decide in the ticket if we move? 18:43:22 on the ticket is fine 18:43:26 i think if everyone responds, we should be able to do it in the ticket 18:43:35 ok 18:43:48 #info will schedule next weeks meeting based on ticket feedback. 18:44:12 #topic Updates policy / Vision implementation status 18:44:12 .fesco 351 18:44:12 .fesco 382 18:44:13 nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351 18:44:17 nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382 18:44:25 ok, our usual updates tickets. ;) 18:44:53 I've gathered all the feedback I could from the mailing list and dumped all the ideas for adjusting the updates policy into a wiki page 18:44:58 https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Changes_Ideas_Container 18:45:18 so, I'm not sure how best to approach this. 18:45:42 Perhaps everyone over the next week could go thru the ideas and filter out the ones that they would like us to implement/do... 18:45:58 then we can discuss and vote on those next week, and drop the ones that no person championed? 18:46:20 Sure 18:46:20 sounds good 18:46:22 yeah, i'd like to read those over 18:47:14 Theres a lot of misc ideas. People do want adjustments. ;) 18:47:30 #info will review ideas container and discuss specific ideas next week. 18:47:49 also under updates we have: 18:48:02 * Need work on stats to see trends with new policy. 18:48:08 * Need to investigate a 'new features' repo setup. 18:48:23 I think lmacken has been working on improving the bodhi stats. 18:48:39 I think kylem was going to work on newfeatures repo 18:49:00 So, any further actions on updates policy for now? Or keep plugging away? 18:49:19 nothing from me for now 18:49:42 Ditto 18:49:51 * nirik notes he also posted to test list for QA feedback/ideas on adjusting the policy. 18:50:16 ok, shall we move on then? 18:50:33 #topic Fedora 12 EOL (2010-12-02) 18:50:33 https://fedorahosted.org/fesco/ticket/486 18:50:41 f12 goes end of life tomorrow. 18:51:13 The hopefully final push goes out later today... unless something breaks badly, then we can do another tomorrow. 18:51:42 Looks good to me 18:51:53 There was a bit of talk in fedora-qa about adjusting the EOL policy to spam pending updates a few weeks before eol. 18:52:10 ie, "Hey, only 2 weeks left, test soon" 18:52:56 that seems slightly odd 18:53:12 but that's the same with critpath and doesn't help in all cases for F-13 18:53:13 i mean again what we're doing here is wondering how many people actually use the n-2 distro 18:53:25 yeah, not sure how we would want it to work... but in any case thats not going to happen for f12. ;) 18:53:42 ajax: we have stats for that 18:55:00 at least, we can get counts of people hitting the mirrorlist 18:55:15 #info Fedora 12 goes EOL tomorrow. 18:56:22 so do we wish to adjust the eol process at this time? 18:57:04 do we send any warnings to the users list as EOL approaches? 18:57:13 i admit to not being on it, devel@ is noisy enough 18:57:15 how many updates is waiting? 18:57:23 ajax: I sent out a announcement to fedora-announce a few weeks ago. 18:57:33 I mean, it's possible that qa can test it in few days? 18:57:52 there are 101 f12 updates in updates-testing. 18:58:00 many of them really really old. 18:58:47 * nirik would also prefer to avoid "hey, lets test and promote all these updates on the last day" because then if something breaks people are out of luck. ;( 18:58:53 yep. 18:59:09 I would push only security... 19:00:04 well, I think it's too late to do much about f12, but if people have ideas for changing it for f13, we can look at them. 19:00:45 nirik: I believe we should solve lack of testing in F-13 before speaking about n-2 19:01:21 sure. 19:01:37 so, solicit ideas for changing/adjusting the EOL process and move on for now? 19:02:34 Yeah 19:02:52 #info ideas/suggestions to improve fedora EOL process welcome. 19:03:16 #topic #501 Fixing the glibc adobe flash incompatibility 19:03:16 https://fedorahosted.org/fesco/ticket/501 19:03:32 "don't" seems to be the winning strategy here 19:03:39 * nirik notes there is a new 64bit flash plugin that fixes this issue for flash at least. 19:03:58 there is? 19:04:28 notting: http://forums.fedoraforum.org/showthread.php?t=205642 19:04:59 notting: Adobe forgot to update their site 19:05:40 then i'm fine with just saying 'no' 19:05:41 leigh123linux: that new binary, which i am running right now, does not fix it 19:05:42 or announce it in any other way. ;) 19:06:10 linus makes a case for reverting this change in https://bugzilla.redhat.com/show_bug.cgi?id=638477#c132 19:06:20 daumas: it does here. are you sure you are using the new one? 19:07:31 nirik: i will retest with a vanilla binary. I had to perform the memcpy->memmove patch. 19:08:27 anyhow, my take on this is: a) we shouldn't revert for flash, and it's fixed anyhow. b) If there is a good technical reason to revert (like linuses plea), we should let the glibc maintainers weigh that, we shouldn't try and force them to do anything. 19:08:40 nirik: Yeah, I'm +1 for that 19:09:07 could we post this link into bugzilla? users could say whether it's fixed for them 19:09:08 so, at most we should ping the glibc maintainers and ask them to revisit based on linuses comment/reply to that. 19:09:17 mmaslano: sure. I can do that. 19:09:47 agree with nirik's assessment 19:10:15 ok, other votes? 19:10:22 +1 to nirik 19:10:38 +1 (if it wasn't clear) 19:10:44 +1 to nirik 19:11:01 nirik: confirmed again with vanilla binary. still broken for me. 19:11:31 daumas: odd. I can work with you in #fedora or something after the meeting? it's sure fixed here. 19:12:07 nirik: sounds good. 19:12:46 ok, so that sounds like it passed. 19:13:15 #agreed No forced revert of glibc changes. Will ask glibc maintainers to review the technical reasons to revert again. 19:13:27 #topic #503 Robotics Spin a Feature? 19:13:27 https://fedorahosted.org/fesco/ticket/503 19:13:37 Not sure what to do here... as spins are somewhat in limbo. 19:14:08 * rmattes (feature co-owner) is around 19:14:40 if this will be feature, then next Fedora could have a lot "spins" features 19:14:40 well in the "features are publicity" sense, sure, this sounds fine. 19:15:18 some background: the spins sig doesn't get much participation. Bruno acted as 'spins wrangler' last cycle... but has no desire to do so for this. 19:15:32 so, the thought was to revisit the spins process at fudcon time. 19:15:43 more background: I recently sent in a request to the board advisory list to take a high-level look at the whole area of spins 19:15:57 see if a spins sig makes sense, or move it back to under rel-eng somehow, or make each sig responsible, or something else. 19:16:04 adamw: yeah. 19:16:16 i'm entirely willing to table this until we have board guidance 19:16:18 (though now i look at the archives, i don't see that it made it through.) 19:17:14 adamw: I was just about to ask for a subject or link ;-) 19:17:33 abadger1999: i guess i'll subscribe to the list and send it again, i was hoping it'd get through moderation but it looks like it just got dropped 19:17:54 yeah, I think it makes sense to table this until we know the fate of spins. 19:18:02 +1 to that 19:18:29 abadger1999: here's the email i sent / will re-send, for reference: http://fpaste.org/QUPB/ 19:20:13 ok, any other votes? 19:20:21 +1 to table 19:20:22 +1 19:20:25 rmattes: is it ok for us to defer until we know more on this from your side? 19:20:53 That's fine, i'd just like to note that fudcon starts about a week after the feature submission deadline 19:21:08 #agreed will table this item until we know more about the fate of the spins sig. 19:21:21 rmattes: yeah, we need to figure out broad strokes well before then. 19:21:53 #topic #504 Which services should be on by default 19:21:53 https://fedorahosted.org/fesco/ticket/504 19:22:41 did we have any kind of guideline for this in the sysvinit scripts ? 19:22:48 not specifically, no 19:23:34 can anyone think of some simple rule? 'if it's critical path it may at the maintainers discretion be enabled by default' ? 19:23:37 Why would anyone install a package that's not enabled? 19:23:45 huh? 19:23:55 I mean 19:24:05 "Why would anyone install a package if they don't want it enabled?" 19:24:19 but many services are by default off 19:24:22 because it may require configuration before enabling it? 19:24:36 * abadger1999 notes that he still thinks this is an fpc issue not a fesco issue. 19:24:39 nirik: That one's an excellent argument 19:24:56 abadger1999: Given that it affects how the system works, I think it's appropriate for fesco 19:25:09 mjg59: All the packaging guidelines affect how the system works. 19:25:17 abadger1999: This one's far more behavioural 19:25:25 spot: Hey, we should have talked about his one in the fpc meeting this morning :-( 19:25:32 mjg59: How so? 19:25:43 perhaps it would be approprate to punt back to FPC and ask them to figure out what they want us to decide? :) 19:25:57 you could make the argument that it goes all the way back to the target audience, etc 19:26:05 mjg59: We already have rules around this -- the only difference is that we don't say which packages are allkowed to break those rules. 19:26:24 My preference would be that services be enabled by default and check whether or not they're configured before starting 19:26:28 So configuration -> enabled 19:26:52 this is the key point. we just need FESCo to advise us if there are any cases where systems should be enabled by default, and if so, what they are. 19:27:00 errr services, not systems. 19:27:08 spot: I think services should be enabled by default if they're installed on a running system 19:27:09 spot: I think that that's an FPC decision really. 19:27:25 mjg59: that's a fairly large change in policy 19:27:31 notting: Well, we were asked 19:27:38 I would leave it as it is 19:27:41 spot: IIRC we (FPC) already say that network facing services can not be enabled by default. 19:27:53 abadger1999: that's correct. 19:28:03 If asked, I'd vote for no services on by default, period. The installer can enable some if necessary. 19:28:03 I grant that there's arguably an exception for network services, but at the same time the default firewall rules would seem to handle that case 19:28:13 spot: So the decision about other services is just an extension of that. 19:28:22 I just don't understand why anyone would want to install a package unless they want that package to function 19:28:25 mjg59: but then there's the request to disable the firewall 19:28:47 notting: I think those are two different aspects of the same problem 19:28:47 mjg59: You've not used a distro with an 'everything' install option, then? 19:28:49 (and thus something fpc decides) 19:28:53 mjg59: probably because our package groups aren't clearly enough defined to make that useful 19:29:17 notting: That's definitely something I agree with, but the fix for that would seem to be to fix our packaging groups 19:29:37 agh. really sorry, had it written as 2:30 in my calendar. 19:29:52 Installing package groups locally increases the attack surface regardless of whether or not any services are started 19:30:01 kylem: no problem. 19:31:35 I think it's ridiculous that someone should have to install a package, enable the service *and* poke a hole in the firewall in order to have it work 19:31:38 * nirik would be ok with 'no for network facing' or 'no, nothing by default, you have to enable it', but that might have impact on install/anaconda/livecd-tools. 19:31:41 That's two steps too many 19:31:44 Well 19:31:47 It's at least one step too many 19:32:08 and start it (if they don't reboot) 19:32:19 i don't think we want to put the entirety of 'what sort of system are you installing, and why/how' decision on anaconda 19:32:41 don't think they have the time at this point of the cycles to make the necessary changes to accommodate that 19:32:43 it would be kinda nice to have it consistent. 19:32:52 notting: I'm not saying that this should change tomorrow 19:34:09 Just that "Should services be enabled or disabled" sounds to me like the wrong question 19:34:23 mjg59: it's the question we have now. ;) 19:34:35 nirik: Well, I vote we send it back to fpc and ask them to ask the right question :p 19:35:03 ie, short term we kinda need to figure this out. Long term I agree it would be great for everything to enable and start. 19:35:29 for that tho, we would need dbus-firewall changes or something, a requirement that all network services be secure out of the box, etc. 19:35:41 Yeah, there's a pile of stuff to handle here 19:36:04 So I guess to answer the question, I'd say "Services don't get to start by default until we have a sane and consistent policy" 19:36:20 And then start working on that sane and consistent policy 19:37:00 * nirik is fine with that, but then there are some that are needed to be running for normal operation of the base OS. 19:37:23 but there would need to be exceptions to that otherwise we're in for more work. are we saying we should officially document those exceptions? 19:38:22 or ask FPC to document/handle exceptions. ;) 19:38:30 * nirik tries to pass the buck. ;) 19:38:48 * abadger1999 wants the buck passed but not sure if spot disagrees ;-) 19:39:08 i have no problem with letting FPC do it 19:39:41 On the assumption that consistency is better than inconsistency, even if I think the current consistency is consistently wrong 19:39:56 proposal: default is off, exceptions exist to allow proper functioning of the os. FPC to document exceptions and process exception requests? 19:40:48 sure. +1 19:40:52 +1 proposal 19:40:59 i expect those who package the exceptions already know who they are 19:41:15 +1. 19:42:09 +1 19:42:27 #agreed default is off, exceptions exist to allow proper functioning of the os. FPC to document exceptions and process exception requests 19:42:43 #topic Open Floor 19:42:51 Anyone have any items for open floor? 19:42:54 we're out of features? 19:43:42 There's this if people want to look: https://fedorahosted.org/fesco/ticket/505 19:43:52 I didn't get them in time for this weeks agenda... 19:43:58 we can go over them if folks would like. 19:44:22 yeah, if they don't next week is fine. 19:44:26 abadger1999: I think next week 19:44:36 abadger1999: There's not really enough time between fpc and fesco to read over the context 19:45:19 we may want to take that into account in scheduling and bias the new meeting time later in the week? 19:45:50 mjg59: Yep, you guys obviously have to stop scheduling the meeting to conflict with us ;-) 19:46:27 we could just meet at the same time! :) more challenge. 19:46:50 Oooh.... and in the same channel! 19:47:02 warring topics. ;) 19:47:08 great, it would be earlier 19:47:18 anyhow, anyone have anything for open floor? or shall we call it a meeting? 19:47:26 * abadger1999 stops making jokes so people can do real work. 19:47:34 heh, sorry for being late. i'll update my calendar for the future. :/ 19:48:12 kylem: yeah, we are also going to try another round of 'when can we meet'. See the ticket with the whenisgood link. 19:48:19 sure. thanks. 19:48:34 ok, thanks for coming everyone! 19:48:38 #endmeeting