18:00:36 #startmeeting Fedora releng 18:00:36 Meeting started Mon Nov 30 18:00:36 2009 UTC. The chair is Oxf13. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:36 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:46 #meetingname fedora-releng 18:00:46 The meeting name has been set to 'fedora-releng' 18:00:55 #topic Roll Call 18:01:14 * poelcat here 18:01:21 ping: Notting spot jwb warren wwoods lmacken rdieter dgilmore poelcat 18:01:28 here 18:01:28 hm? 18:01:30 oh 18:01:34 hola 18:01:36 hrm, no notting. 18:01:37 here for 29min 18:01:44 * spot waves 18:01:46 * dgilmore is present 18:02:37 * wwoods lurks 18:03:06 ok 18:03:19 The only real topic I think we have this week is the F13 schedule 18:03:24 #topic Fedora 13 Schedule 18:03:31 poelcat: care to recap where we are with that? 18:04:22 * poelcat put it all in the ticket 18:04:32 and can't quite remember :) 18:04:40 .rel 3169 18:04:42 Oxf13: #3169 (Finalize Fedora 13 Schedule) - Fedora Release Engineering - Trac - https://fedorahosted.org/rel-eng/ticket/3169 18:05:27 * poelcat is hoping we can get some feedback from stickster_afk once he returns 18:05:33 We were 1) waiting for go/nogo adjustment feedback. 2) decision on how to land our dates vs Ubuntu and OpenSUSE 18:05:47 yeah, when do we expect that to go non-afk? 18:06:08 today EOD I believe 18:06:26 ok, so not likely to resolve F13 scheduling today. 18:06:41 re #3 in ticket... mdomsch gave a good reply on f-i-l 18:06:53 and nobody is approving my subscription to mirror list 18:07:10 and #4 seems like desktop group is as good as they're going to be 18:07:13 hrm, I'm not sure who manages that list as far as subscriptions and such. I can post there for you to save time. 18:07:15 who runs mirror list? 18:07:30 warren: pretty sure that's administrated by RHT internals 18:07:33 a bunch of guys w/ @rht.com 18:07:43 * poelcat wonders why 18:08:05 if the whole point of the mirrors is to not affect "internal" 18:08:20 last vestiges from when RHT IS handled putting bits up for mirrors, and handled ACLs on the mirrors 18:08:35 sorry i'm late 18:08:35 some things are slow to migrate 18:08:47 Oxf13: you could fwd my mail to f-i-l 18:08:50 I think RHT IS still has to fiddle with the ACLs for mirrors to get access. 18:08:51 have we filed a ticket to get ownership of that list transferred? 18:08:55 poelcat: can do. 18:08:56 oh 18:08:57 but i feel like mdomsch gave us the data we needed 18:09:15 Oxf13: i thought we moved the masters and gained control of it 18:09:15 poelcat: I agree, and I fall on the side of pushing 2 weeks 18:09:33 dgilmore: we gained control over putting content on, but I don't think we manage the ACLs on the rsync modules 18:09:42 * poelcat thinks 1 week is enough 18:10:14 Oxf13: i know we set up some boxes with mirror rsync acceess 18:10:27 combined with our historical on-time performance 18:10:28 poelcat: one week would put us staging while Ubuntu was releasing, not a good scenario 18:10:34 not sure if they are now considered master or not 18:10:48 poelcat: I'd rather not plan for failure to make us hit our dates. We'd have to fail in order to avoid conflict, and that seems wrong. 18:11:35 Oxf13, why isn't that a good scenario? 18:12:03 jwb: because if by some miracle we don't slip any of our previous dates, we'll have to slip for no other reason than "we didn't plan right in the first place" 18:12:18 Oxf13: i think there are multiple ways to look at it 18:12:23 Oxf13, i was talking about the us staging/ubuntu shipping thing 18:12:39 and given the amount of work we've done on early detection of slip worthy scenarios, and the fact that we didn't have to slip our last date, I think we actually have a chance at not needing to slip alpha/beta/final 18:12:40 #info https://www.redhat.com/archives/fedora-infrastructure-list/2009-November/msg00159.html 18:13:00 jwb: the mirrors will be very busy with people downloading ubuntu, and won't have bandwidth/disk resources to stage our release 18:13:06 Oxf13: given that we've been 2+ weeks late since F8 I don't see the basis for it 18:13:32 poelcat: I think you've given up on our ability to improve. 18:13:41 Oxf13, i see 18:13:47 now you're putting words in my mouth :) 18:14:01 poelcat: how else am I supposed to take that? 18:14:14 i say we add one week and work super hard to hit it 18:14:22 so when do we get to dictate to ubuntu that they need to slip? :) 18:14:23 i'm referring to the data, you're saying I'm being negative 18:14:40 poelcat: you're referring to only part of the data 18:14:50 poelcat: you're not taking into account the work we're doing to improve, based on the data 18:15:03 with significant changes happening 18:15:35 if we were just going to do the same things again without changing anything, sure I'd also assume that the trend will play out and we'll be 2 weeks late 18:15:38 and you've said that every release and we've still been 2+ weeks late each release 18:15:48 poelcat: we haven't made such significant changes every release 18:15:54 lol 18:16:04 that's not what you told me before :) 18:16:06 but hey, keep calling me a failure, I enjoy that. 18:16:19 Oxf13: this is counter productive 18:16:33 you're right. 18:16:38 bottom line, I refuse to plan to fail. 18:17:22 i tend to agree there 18:17:25 if it were a case that slipping by 2 weeks would put us into conflict with some other project, that'd be one thing, and I'd certainly plan around that. 18:17:36 Oxf13: i agree. i can see adjusting a week. 18:17:37 however in this case, we'd /have/ to slip in order to avoid conflict. 18:17:44 dgilmore: a week doesn't cut it 18:17:51 Oxf13: to accomadte a different distros schedule 18:18:10 dgilmore: pushing our schedule out a week and having no slips would put us staging Fedora 13 at the same time mirrors are trying to take the bunt of the Ubuntu release 18:18:15 but we need to really work on making sure we hit the schedule 18:18:17 that's a scenario the mirrors will ont want. 18:18:29 Oxf13: ok 18:18:37 for the record I'm not advoacting failing 18:18:51 you're just expecting it (: 18:19:07 no 18:19:58 how consistent is Ubuntu with hitting their schedule? 18:20:05 warren: pretty consistant 18:20:20 they are much better at it than we are 18:25:12 do we have actual requests from mirrors to not conflict? 18:25:21 notting_: we have gotten such requests from kernel.org at least 18:25:57 I think there were others, trying to search 18:26:43 not having luck finding as it wasn't in a subject all its own 18:27:36 have to dial into a call. ping me if/when you want a brief update on updates 18:27:45 k 18:27:54 jwb: are there updates on updates other than "PAAAIN"? 18:28:00 yes 18:29:22 #info oxf13 has forwarded John's mail to mirror-list for discussion 18:29:58 but given mdomsch's response, I propose that we adjust our schedule by 2 weeks, such that if we did not slip, we would not conflict with Ubuntu 18:30:34 what happens if we do slip? 18:31:41 lets worry about that if it happens, we might be able to slip a bit past their release 18:31:49 notting_: from what we can tell, further slipping would not run us into any other major distribution milestone 18:32:16 by moving our schedule out 2 weeks, we clear Ubuntu, and would only have to worry about OpenSUSE 18:32:19 i'm mildly concerned about us pre-changing our schedule to accomodate this, and then they (or someone else) slip into our new schedule 18:33:01 notting_: Ubuntu seems to only have had one schedule change, and they did it midstream to accommodate an LTS release 18:33:14 as I said before, they're /much/ better about hitting their dates than we are 18:33:15 +1 spot 18:34:49 Yes, the only schedule change was to shift 6.04 to be two months later 18:35:06 That being the first LTS release 18:36:44 do we have info from the mirrors that staging a release adds too big of a load? 18:36:57 it does for the top tier mirrors 18:37:06 since downstream mirrors hit them a lot to get their data 18:37:18 so staging events do have a significant impact on places like kernel.org 18:37:45 have they told us it is so significant we should not do it? 18:37:55 kernel.org has requested that at least 18:39:33 could we stage in a way that has less impact? Everything will land a lot earlyer. 18:39:54 at f14 branch point right? 18:39:55 nirik: not really, the isos are the big hit 18:40:04 well 18:40:21 the everything tree is a hit too as a fair number of downstream mirrors don't mirror rawhide, so they see a huge amount of files as new 18:40:31 but the isos are behind the bit flip? or they mean lower tiered official mirrors that sync that from them? 18:40:39 and I suspect that because of that, we're oging ot have to move that tree to outside of the releases/ path until it's GOLD 18:40:54 nirik: lower tiered official mirrors 18:41:29 * nirik just wonders if the reason they requested that was that everything and isos hit the same time last cycle... 18:42:09 nirik: no, I talked a bit to hpa and warthog about it. 18:42:39 having everythign and isos land at different times does help the issue, but the isos are big enough that landing them while Ubuntu is going crazy with downloads would not be healthy for our mirror system 18:42:52 it would threaten our ability to have enough mirrors ready to open at release day 18:44:43 Oxf13: so you're set on 2 weeks... nothing else to consider or sway you? 18:45:11 poelcat: enough -1 votes from other releng members. 18:45:38 I just don't like planning for a situation where we have to fail in order to succeed 18:46:30 i would agree 18:48:26 assumption: all dates move forward the same amount? 18:48:28 if we aren't going to get any new information that will help us decide i guess it is time to decide? 18:49:08 notting_: my assumption was add two week to front of schedule and hold freeze lengths the same, etc. 18:49:11 notting_: that's probably best to avoid another 2 weeks of fine tuning / arguing (: 18:49:37 so more devel time :) 18:50:47 not the worst thing in the world. 18:53:02 http://poelstra.fedorapeople.org/schedules/f-13-draft/f-13-two-more.html 18:53:34 #idea Extend development time by 2 weeks in order to push our schedule 2 weeks later and avoid Ubuntu release conflicts for both our release and our staging. 18:53:37 +1 18:54:50 lets get this voted on and approved 18:55:44 +1 with minor reservations 18:56:50 i'm not exactly thrilled with having to move just for external concerns. but given that that is apparently required, sure, +1 18:57:51 notting_: I'm not thrilled either, but I think it'd be pretty shitty of us to ignore these requests 18:58:15 +1 18:59:23 Oxf13: so first response to mirror query was needing 7 days, not 2 weeks 18:59:29 if i understood it correctly 18:59:48 poelcat: yea, he's likely a downstream mirror, not a tier1 19:00:06 for downstream mirrors 7 days is likely fine. For tier1, it isn't. 19:00:41 tier1s would be trying to service users downloading Ubuntu, while at the same time trying to service tier2+ mirrors staging Fedora 19:02:43 dgilmore jwb spot lmacken warren any of you have opinions on this matter? 19:03:01 i think you spent about 20 minutes more than necessary discussing it. 19:03:13 does that count as an opinion? 19:03:19 i haven't paid attention for about 30 min, but i agreed with your 'i refuse to plan to fail' 19:03:31 spot: if you'd like, i could go back to a couple of other discussions on other lists. i'm sure that will be fun. 19:03:36 I would prefer failing to plan. 19:03:52 notting_: no thanks, i'm going to go offline and be a dick. 19:04:16 spot: wait, you're tom *and* dick? who's harry? 19:04:27 notting_: can't keep track these days. 19:04:38 I can't vote either way on this issue, while I agree we don't want to plan to fail, how many times have we realistically hit deadlines? once? 19:04:38 notting_: I am, everywhere except for my head 19:04:54 Oxf13: TMI. 19:05:28 warren: if us slipping would put us into conflict I'd agree to that line of thinking. But us slipping wouldn't. 19:05:35 Oxf13: im ok with it 19:06:00 +1 19:06:20 Ok, I think that's enough votes 19:06:51 #agreed schedule will be moved 2 weeks later by adding 2 weeks to development time in order to clear conflicts with ubuntu release. 19:07:00 #topic LXDE respin 19:07:16 .fesco 280 19:07:17 Oxf13: #280 (Compose of fixed LXDE spin images) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/280 19:07:55 * dgilmore is ok with repining and releaseing. but we need some way to let people know that teh sources for the updated packages are available elsewhere. say Chitlishs Fedora people page 19:08:15 ok, background 19:08:16 chitlesh is FEL. cwickert is LXDE. 19:08:18 LXDE spin was broken 19:08:23 we pulled it 19:08:26 opps my bad 19:08:34 and now they have it fixed with one package update. 19:08:37 cwickerts fedora people page 19:08:48 My recommendation to them has been that we respin the LXDE spin with the updated package, and add the srpm to the torrent 19:09:07 why that? 19:09:08 that way they get the updated srpm when they get the binaries, the README-SOURCES file points them to the rest of the sources 19:09:30 * nirik notes there are 5 fesco votes now for this, so... make it so! :) 19:09:45 and we don't have to worry about adding an srpm somewhere to be kept live until the torrent goes away 19:09:52 sorry, I don't get it. why has the srpm to be in the torrent? 19:10:00 cwickert: we comply with the GPL source availability by spinning the ISOs from the gold tree, and we can then point people at the never-changing Everything tree 19:10:16 cwickert: if you pull in an update, that later gets obsoleted in updates/, where would the user get the corresponding source? 19:10:29 I see 19:10:37 cwickert: We have to make the sources used to produce the spin available for as long as the binary spin is available. 19:10:48 generally we do that by pointing to the Everything/ tree on the mirror 19:10:53 what about shipping the spin without the update? 19:10:54 Oxf13: adding the srpm to the iso would be ok also 19:11:08 cwickert: shipping the spin without the update would result in a broken spin 19:11:13 no 19:11:16 dgilmore: it would, but that's a bit harder to do 19:11:25 the only reason to ship it is that update declared it as a secutiry update 19:11:34 see the discussion in bodhi 19:12:04 and I doubt it's really security sensitive 19:12:21 we can fix this with only with working around the crash in the spec 19:12:28 "the spec" ? 19:12:30 the spec of what? 19:12:33 sorry, ks 19:12:55 so it just needs a ks change, no package change now? 19:13:24 right, I though that was from the ticket and the linked update 19:13:26 by disabling the screensaver 19:13:41 that change doesn't carry over to the installed image does it? 19:13:55 ? 19:14:12 no it doesn't , it's only on the livesystem 19:14:17 cwickert: oh, sorry... got confused then. If we just need a ks change and no rpm change, thats fine. 19:14:29 on the other hand I don't want to ship a spin without a known security problem 19:14:39 with? :) 19:14:48 s/don't want/dislike 19:15:01 sorry notting, without the update, with the problem 19:15:09 you mean the PK thing? 19:15:22 no 19:15:26 menu-cache 19:15:32 doesn't look like a security thing to me 19:15:34 as linked in the ticket 19:15:45 not for me ether, but upstream says so 19:15:56 did they file a CVE? 19:16:01 but he doesn't provide any details, not even in private mail 19:16:07 wait a sec 19:16:21 is the discussion of whether or not to include this one update really a rel-eng issue? 19:16:57 * cwickert was told it's a fecso thing btw 19:17:31 that's true 19:17:38 seems FESCo already voted to ship with the update 19:17:47 but that may have been under the assumption that the update was necessary to fix the problem 19:17:59 yes, thats the way I read it. 19:18:15 that's the way it reads to me too :/ 19:18:17 cwickert: that ticket seems to indicate that menu-cache is required to fix the issue. 19:18:21 * cwickert aplogized for assuming people actually read the link he provided 19:18:24 not that it's some incidental security update. 19:18:41 which link? 19:18:53 'menu-cache-0.2.6 update' is a link to bodhi 19:19:06 with details: 19:19:07 This update removes several references to invalid pointers and fixes some memory leaks. It also fixes a crash when menu-cache-gen was called by several different programs at the same time. 19:19:29 yeah, so I read that as it was part of the crashing problem and needed to be in it to fix it. 19:19:43 it's somewhat difficult to infer from this information that it is /not/ related to the "serious error" that caused us to with drawl LXDE 19:19:52 which probably should be noted in the ticket for consideration, and then discussed at the fesco level (not here) 19:20:06 sorry if it was unclear 19:20:10 so I guess the releng question is, do we kick this back up to FESCo given new information, or just take the update and run? 19:20:54 'back to'? there was no fesco decision so far 19:20:59 #info New information regarding LXDE update, seems only a .ks change is required to fix the original issue. THe updated package is for a separate and non-fatal issue. 19:21:14 cwickert: there were enough votes on the ticket to approve it 19:21:22 ok, I see 19:21:53 #idea Given new information, I propose the FESCo ticket gets updated and another vote happens at the FESCo level as to ship just the .ks change or include the questionable security update. 19:21:58 I'm +1 on that idea. 19:22:10 oops, i already updated the ticket 19:22:12 cwickert: if it goes fast enough, I can still get it spun up today 19:22:20 notting_: I'll take that as a +1 then (: 19:22:48 well, not really. a +1 to it as a rel-eng decision, as with my fesco hat on, i'm not sure it's rel-eng business 19:22:49 if that makes sense 19:22:55 fact is, that there are people waiting for the spin. we had nearly twice as much LXDE downloads than Xfce and I get mails every day, so I really like to have a decision, no matter what it is 19:23:12 Oxf13: that would eb great 19:23:15 Oxf13: as long as the installed system is ok then im +1 19:23:20 it is 19:23:26 no changes to the packages 19:24:12 cwickert: and with a ks change the installed system will work just fine 19:24:18 * nirik wonders if we just have enough people here to vote now. 19:24:23 the only issue is that the installed system has a known security issue, that gets fixed with the first update. I guesss this is similar to PK, so I think we can go with that 19:24:44 cwickert: based on your earlier comments i thought it was only on the live system and did not transfer to the installed one 19:25:03 dgilmore: the basic problem only occurs in the live environment 19:25:10 "no changes to the packages" means no change to the installed system 19:25:11 dgilmore: it does not occur if you do an LXDE installation 19:25:18 Oxf13: ok 19:25:25 right, the installed system had no crash at all 19:27:37 the more changes we make the higher the chance some security update messes up something else. 19:27:52 so I would say as few changes as possible, ie, just the ks change. 19:28:28 * jwb moves on to next phone call and re-iterates his statement about updates ping 19:28:52 * notting_ thinks we should move onto updates 19:29:00 yeah 19:29:12 #agreed LXDE respin decision kicked back up to FESCo in light of new information. 19:29:18 #topic Updates 19:29:23 jwb: you have the floor 19:29:52 so a couple of quick items 19:30:02 1) last f10 updates push is dec 11 19:30:09 i sent this to f-d-a 19:30:43 2) i've now been signing the f1[12]-updates-candidate tags on an ongoing basis. this has helped with signing run times quite a bit 19:30:52 but i have no idea what it's doing to the koji storage 19:31:22 We may have to adjust our garbage collection wrt signed packages. 19:31:29 but we needed to revisit that anyway 19:32:00 i sent some rambles to the list about possible bodhi improvements. luke liked most of them, but getting them done depends on lots of factors 19:33:10 right 19:34:59 jwb: anything else on updates? 19:35:19 nope, that was it. looking forward to push times going down temporarily with f10 dying 19:35:53 whee! 19:40:29 #topic open floor 19:40:36 anybody got anything? We're 40 minutes over :/ 19:40:56 * notting_ does not 19:45:31 #endmeeting