17:30:01 #startmeeting FESCO (2011-03-09) 17:30:01 Meeting started Wed Mar 9 17:30:01 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:01 #meetingname fesco 17:30:01 #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:01 The meeting name has been set to 'fesco' 17:30:01 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:29 nirik, congrats. 17:30:38 welcome, and stuff. 17:30:44 thanks. 17:31:00 * mclasen forgot and is entirely unprepared 17:31:02 * notting is here 17:31:31 * cwickert is here 17:31:34 Here 17:32:24 ok, I guess we can go ahead and dive in. ;) 17:32:31 * ajax waves 17:32:42 First a topic I didn't have on the agenda, but we should hit... 17:32:49 #topic Our good friend, DST 17:33:00 Daylight savings time is coming up this next weekend... 17:33:10 so do we move our meeting an hour, or keep it the same UTC time? 17:33:52 there's the week of overlap where US changes before EU changes, correct? 17:33:59 yeah, as I recall. 17:34:16 no preference, my wednesday schedule is pretty flexible 17:34:37 oops, two weeks. 17:34:48 march 28th looks like. 17:34:59 Works for me 17:35:46 * nirik doesn't care too much either way. 17:35:49 * mclasen is flexible too 17:36:27 ** me is too but would prefert to stick with the current time one more week 17:36:37 ok, so I guess just keep it at the same UTC time for now? 17:36:41 +1 17:37:30 any objections? we can always revisit later I guess... 17:37:50 no objection here 17:37:54 no big deal 17:37:58 +1 17:37:59 ack. 17:38:11 #agreed will stick to the same UTC time for meetings for now. 17:38:15 #topic #516 Updates policy adjustments/changes 17:38:15 .fesco 516 17:38:16 nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516 17:38:20 ok, so 2 more this week... 17:38:55 1: enforced min number of days in testing for some updates 17:39:32 This was suggested I think due to some updates getting a bunch of karma before they even hit testing and going stable... the suggestor wanted to make sure they always had some time in testing. 17:40:25 i think as long as the testing is good testing, then i don't see a problem with them going out quickly 17:41:10 depends on whether that karma is just people gaming the system i guess 17:41:15 #info mmaslano voted -1 in ticket 17:41:28 there is one problems with updates getting karma too quickly 17:41:37 but that is just for pre-release updates, I think 17:42:01 where the update gets moved out of updates-testing and then effectively becomes unavailable until a freeze lifts 17:42:47 mclasen: that ... shouldn't happen 17:43:21 it has hit us repeatedly during the f15alpha freeze, I think 17:43:38 we shouldn't be pushing stable updates during a freeze, so things shouldn't be getting moved 17:43:42 * nirik nods. 17:44:09 * mclasen has to ask halfline for the details, I think it was probably just some bodhi bug 17:44:13 mclasen: when you next notice it can you let folks know and we can figure out whats going on? 17:44:35 * mclasen turns around and finds halfline is not there...I'll follow up 17:44:41 anyhow, I am -1 for this one at this time... if testing is good there's no issue with them going quickly. If it's bad, we should correct the testing process. 17:45:18 sounds right to me 17:45:21 any other discussion/votes? 17:45:34 * notting is -1 17:45:40 -1 17:45:56 -1 17:46:06 are we currently forcing updates through autoqa ? 17:46:22 #action this suggestion is declined at this time. 17:46:35 mclasen: not that I know of... or not that it's doing anything to them. ;) 17:46:42 :-( 17:46:49 but hopefully someday... 17:47:03 item2: updates that only modify the spec could have a lower requirement. (ie, to fix a packaging issue, no changes in the upstream software). 17:47:29 heh 17:47:31 this was on the idea that you are fixing a packaging bug like a missing requires... it would be easier to check/test that. 17:47:49 i'm +1 on the idea, but i think it's not really enforceable. 17:47:57 of course it's hard to quantify what a 'minor' change would be here... 17:48:06 autoqa would help for that as well, it could tell us 'this package is essentially unchanged' 17:48:56 mclasen: you'll get rpmlint/rpmguard mail for each update 17:49:02 yeah, and obvious simple changes could be easy to test, which would mean more karma so they pass thru quicker anyhow 17:49:17 #info mmaslano voted 0 in ticket on this issue. 17:49:40 A spec change could include passing different arguments to configure 17:50:11 So I think it would need to be limited to certain parts of the spec file 17:50:14 define "a lower requirement" 17:50:40 I think 'spec change' is really besides the point here 17:50:46 I don't think that we can distinguish different types of updates 17:50:51 a new upstream tarball might just as well only fix a typo in the docs... 17:50:59 fewer days in testing required, less karma, proventester not needed. 17:51:25 shouldn't a 'minor' update be easier to test, and get the required feedback with? 17:51:50 notting: yeah, I would think so... 17:51:54 am an not sure if it is a good idea, basically we are saying upstream updates are dangerous while packaging can do no harm 17:52:09 right, which could not at all be the case. 17:52:14 Yeah, definitely leaning -1 17:52:17 * nirik is -1 for this suggestion as well. 17:52:22 and I doubt that there is a technical way to enforce it 17:52:24 so -1 17:52:31 * notting is -1 as well 17:52:56 yeah, leaning -1 here 17:53:19 I think thats 5, as long as the leaning is enough? ;) 17:53:23 * mclasen really wants to see autoqa move ahead... 17:53:41 #agreed suggestion is declined at this time. 17:53:46 mclasen: yeah. ;( 17:54:02 #topic #515 Investigate a "features" repo for stable releases 17:54:02 .fesco 515 17:54:03 nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515 17:54:09 cwickert: any news on this at this time? 17:54:22 not really 17:54:38 ok, no worries... 17:54:38 I have started drafing something but I was just too busy due to CeBIT 17:54:48 it's not yet on the wiki yet 17:54:53 we can revisit down the road... 17:55:02 and I guess it's a feature, so we can only target F16 now 17:55:27 probibly. 17:55:57 #topic #517 Updates Metrics 17:55:57 .fesco 517 17:55:58 nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517 17:56:11 any news on this one? 17:56:23 not on my end. 17:56:57 ok, moving on then... 17:57:11 #topic #544 List of services that may start by default 17:57:11 .fesco 544 17:57:12 nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544 17:57:33 last week we wanted to look at dbus activated and if we could use critical path for some of this. 17:57:40 I did not get a chance to investigate here. sorry. 17:58:18 related to this is another topic: ticket #570 Interim autostart policy 17:58:18 .fesco 570 17:58:19 nirik: #570 (Interim autostart policy) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/570 17:58:37 I did not get much chance to dig into this either. ;( 17:59:09 so, do we want to defer another week? or try and move this forward somehow? 17:59:33 i'll try and get to it later this week and update the ticket 17:59:50 * mclasen will ask mezcalero to write about activation, again 18:00:01 I got him to write, just not about activation :-( 18:00:08 #action notting will try and update ticket later this week with more info 18:00:22 #action mclasen will get mezcalero to write about activation. 18:00:33 ok, lets move on then I guess. ;( 18:00:38 i'm not 100% sure what the point of #570 is. isn't the default that the old policy stays until the new policy is approved? why do we need it explicitly? 18:01:05 The new policy seems to spend more time talking about fesco than about policy 18:01:39 notting: I think the idea was to move it so it's explicitly not under Packaging and so they have a place to point 18:01:55 Or am I misinterpreting what's being asked? 18:01:58 ie, look here for this... and the here is the current policy until we finalize a new one. 18:02:14 ie, is the entire text there the policy, or is that page policy and discussion and only the policy would be posted? 18:03:16 * nirik looks for toshio, but he's not around. ;( 18:03:43 he's at ... pycon? some other conference? 18:03:45 I think it was just meant as a placeholder of the current policy for them to point people to until we finalize one. 18:03:47 yeah. 18:04:30 I'm personally fine with that page being pointed at for now... and hopefully we have a new policy soonly. 18:05:05 I'm not enthusiastic about a policy (even a placeholder) that contains so much discussion 18:05:26 I think it's more confusing than helpful 18:06:24 perhaps strike the last 2 sections and replace with "This policy is currently being revised by FESCo. Please check back soon for the new policy" ? 18:07:05 Yeah 18:07:49 wfm 18:08:02 any objections to that? I can add that to the ticket for toshio to comment on when he's around. 18:08:47 #action will suggest amending the draft autostart page a bit and put in place until we can finalize the new policy. 18:08:59 * nirik will move on in a few then... 18:09:16 #topic #563 suggested policy: all daemons must set RELRO and PIE flags 18:09:16 .fesco 563 18:09:17 nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563 18:09:22 any news on this one? 18:09:29 yeah, i'm working on an email about it 18:09:37 i spent the early bits of this week benchmarking 18:10:00 cool. 18:10:04 i'll follow up with it today/tomorrow 18:10:59 cool. how does it look? or still gathering/checking? 18:11:39 on the bits of the desktop i rebuilt, there's no benchmarkable difference 18:11:47 i'm profiling atm to see if i can spot anything that way 18:12:12 thats with both relro and pie? 18:12:27 well, pie executables and relro on everything, yeah 18:13:16 cool. Hopefully we can just enable it and be done with it... 18:13:26 yeah, i'm still waiting to hear back from the toolchain people 18:13:34 i'll send another email today if i don't hear back soon 18:13:37 #info kylem will send out a email on benchmarking results in the next few days. 18:13:49 ok, anything else here, or shall we move on? 18:13:57 not from me 18:14:30 Sounds good to me 18:14:44 #topic FES tickets 18:14:47 https://fedorahosted.org/fedora-engineering-services/report/6 18:14:57 RobbieAB I don't think could make it today. 18:15:02 * mclasen_ gets roped into another meeting 18:15:16 got a bit more tickets moving, but hopefully we can ping more and get it back to full speed soon. 18:15:33 as always, if you think of tickets/issues/ideas that could be good for this, feel free to file them. 18:15:58 * nirik will move on to open floor if nothing else on fes in a few. 18:16:41 #topic Open Floor 18:16:46 anything for open floor? 18:17:10 hope not. shortest meeting evar. :) 18:17:18 * gholms raises hand 18:17:29 Oh, just FYI, I may not be around the first week in April, so someone else will need to run the meeting most likely. 18:17:34 gholms: go ahead. 18:17:41 Thanks for slogging through so many of these days' annoying technical problems. 18:17:42 eof 18:17:42 I mailed glibc-owner about the memcpy issue but it failed to get sent due to a miscongifuration at my end 18:17:51 But there's upstream movement on the issue now 18:18:09 mjg59: thats good news. They looking at reverting? or ? 18:18:20 gholms: :) 18:18:37 nirik: Symbol versioning 18:18:45 nirik: Anything built against old glibc would get the old behaviour 18:18:59 ah, interesting. 18:19:01 And building against new glibc would give you the new behaviour 18:19:08 The assumption being that people would test before doing that... 18:20:05 yeah. 18:20:40 ok, anything else? or shall we call it a short meeting? 18:21:42 [A tumbleweed blows by] 18:21:52 ;) 18:21:56 ok, thanks for coming everyone! 18:21:59 #endmeeting