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