18:00:36 <Oxf13> #startmeeting Fedora releng
18:00:36 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:46 <Oxf13> #meetingname fedora-releng
18:00:46 <zodbot> The meeting name has been set to 'fedora-releng'
18:00:55 <Oxf13> #topic Roll Call
18:01:14 * poelcat here
18:01:21 <Oxf13> ping: Notting spot jwb warren wwoods lmacken rdieter dgilmore poelcat
18:01:28 <warren> here
18:01:28 <jwb> hm?
18:01:30 <jwb> oh
18:01:34 <rdieter> hola
18:01:36 <Oxf13> hrm, no notting.
18:01:37 <jwb> here for 29min
18:01:44 * spot waves
18:01:46 * dgilmore is present
18:02:37 * wwoods lurks
18:03:06 <Oxf13> ok
18:03:19 <Oxf13> The only real topic I think we have this week is the F13 schedule
18:03:24 <Oxf13> #topic Fedora 13 Schedule
18:03:31 <Oxf13> poelcat: care to recap where we are with that?
18:04:22 * poelcat put it all in the ticket
18:04:32 <poelcat> and can't quite remember :)
18:04:40 <Oxf13> .rel 3169
18:04:42 <zodbot> 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 <Oxf13> We were 1) waiting for go/nogo adjustment feedback.  2) decision on how to land our dates vs Ubuntu and OpenSUSE
18:05:47 <Oxf13> yeah, when do we expect that to go non-afk?
18:06:08 <poelcat> today EOD I believe
18:06:26 <Oxf13> ok, so not likely to resolve F13 scheduling today.
18:06:41 <poelcat> re #3 in ticket... mdomsch gave a good reply on f-i-l
18:06:53 <poelcat> and nobody is approving my subscription to mirror list
18:07:10 <poelcat> and #4 seems like desktop group is as good as they're going to be
18:07:13 <Oxf13> 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 <warren> who runs mirror list?
18:07:30 <Oxf13> warren: pretty sure that's administrated by RHT internals
18:07:33 <poelcat> a bunch of guys w/ @rht.com
18:07:43 * poelcat wonders why
18:08:05 <poelcat> if the whole point of the mirrors is to not affect "internal"
18:08:20 <Oxf13> last vestiges from when RHT IS handled putting bits up for mirrors, and handled ACLs on the mirrors
18:08:35 <notting> sorry i'm late
18:08:35 <Oxf13> some things are slow to migrate
18:08:47 <poelcat> Oxf13: you could fwd my mail to f-i-l
18:08:50 <Oxf13> I think RHT IS still has to fiddle with the ACLs for mirrors to get access.
18:08:51 <warren> have we filed a ticket to get ownership of that list transferred?
18:08:55 <Oxf13> poelcat: can do.
18:08:56 <warren> oh
18:08:57 <poelcat> but i feel like mdomsch gave us the data we needed
18:09:15 <dgilmore> Oxf13: i thought we moved the masters and gained control of it
18:09:15 <Oxf13> poelcat: I agree, and I fall on the side of pushing 2 weeks
18:09:33 <Oxf13> 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 <dgilmore> Oxf13: i know we set up some boxes with mirror rsync acceess
18:10:27 <poelcat> combined with our historical on-time performance
18:10:28 <Oxf13> poelcat: one week would put us staging while Ubuntu was releasing, not a good scenario
18:10:34 <dgilmore> not sure if they are now considered master or not
18:10:48 <Oxf13> 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 <jwb> Oxf13, why isn't that a good scenario?
18:12:03 <Oxf13> 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 <poelcat> Oxf13: i think there are multiple ways to look at it
18:12:23 <jwb> Oxf13, i was talking about the us staging/ubuntu shipping thing
18:12:39 <Oxf13> 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 <poelcat> #info https://www.redhat.com/archives/fedora-infrastructure-list/2009-November/msg00159.html
18:13:00 <Oxf13> 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 <poelcat> Oxf13: given that we've been 2+ weeks late since F8 I don't see the basis for it
18:13:32 <Oxf13> poelcat: I think you've given up on our ability to improve.
18:13:41 <jwb> Oxf13, i see
18:13:47 <poelcat> now you're putting words in my mouth :)
18:14:01 <Oxf13> poelcat: how else am I supposed to take that?
18:14:14 <dgilmore> i say we add one week and work super hard to hit it
18:14:22 <notting> so when do we get to dictate to ubuntu that they need to slip? :)
18:14:23 <poelcat> i'm referring to the data, you're saying I'm being negative
18:14:40 <Oxf13> poelcat: you're referring to only part of the data
18:14:50 <Oxf13> poelcat: you're not taking into account the work we're doing to improve, based on the data
18:15:03 <Oxf13> with significant changes happening
18:15:35 <Oxf13> 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 <poelcat> and you've said that every release and we've still been 2+ weeks late each release
18:15:48 <Oxf13> poelcat: we haven't made such significant changes every release
18:15:54 <poelcat> lol
18:16:04 <poelcat> that's not what you told me before :)
18:16:06 <Oxf13> but hey, keep calling me a failure, I enjoy that.
18:16:19 <poelcat> Oxf13: this is counter productive
18:16:33 <Oxf13> you're right.
18:16:38 <Oxf13> bottom line, I refuse to plan to fail.
18:17:22 <jwb> i tend to agree there
18:17:25 <Oxf13> 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 <dgilmore> Oxf13: i agree. i can see adjusting a week.
18:17:37 <Oxf13> however in this case, we'd /have/ to slip in order to avoid conflict.
18:17:44 <Oxf13> dgilmore: a week doesn't cut it
18:17:51 <dgilmore> Oxf13: to accomadte a different distros schedule
18:18:10 <Oxf13> 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 <dgilmore> but we need to really work on making sure we hit the schedule
18:18:17 <Oxf13> that's a scenario the mirrors will ont want.
18:18:29 <dgilmore> Oxf13: ok
18:18:37 <poelcat> for the record I'm not advoacting failing
18:18:51 <Oxf13> you're just expecting it (:
18:19:07 <poelcat> no
18:19:58 <warren> how consistent is Ubuntu with hitting their schedule?
18:20:05 <Oxf13> warren: pretty consistant
18:20:20 <Oxf13> they are much better at it than we are
18:25:12 <notting_> do we have actual requests from mirrors to not conflict?
18:25:21 <Oxf13> notting_: we have gotten such requests from kernel.org at least
18:25:57 <Oxf13> I think there were others, trying to search
18:26:43 <Oxf13> not having luck finding as it wasn't in a subject all its own
18:27:36 <jwb> have to dial into a call.  ping me if/when you want a brief update on updates
18:27:45 <Oxf13> k
18:27:54 <notting_> jwb: are there updates on updates other than "PAAAIN"?
18:28:00 <jwb> yes
18:29:22 <Oxf13> #info oxf13 has forwarded John's mail to mirror-list for discussion
18:29:58 <Oxf13> 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 <notting_> what happens if we do slip?
18:31:41 <spot> lets worry about that if it happens, we might be able to slip a bit past their release
18:31:49 <Oxf13> notting_: from what we can tell, further slipping would not run us into any other major distribution milestone
18:32:16 <Oxf13> by moving our schedule out 2 weeks, we clear Ubuntu, and would only have to worry about OpenSUSE
18:32:19 <notting_> 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 <Oxf13> notting_: Ubuntu seems to only have had one schedule change, and they did it midstream to accommodate an LTS release
18:33:14 <Oxf13> as I said before, they're /much/ better about hitting their dates than we are
18:33:15 <Southern_Gentlem> +1 spot
18:34:49 <mjg59> Yes, the only schedule change was to shift 6.04 to be two months later
18:35:06 <mjg59> That being the first LTS release
18:36:44 <poelcat> do we have info from the mirrors that staging a release adds too big of a load?
18:36:57 <Oxf13> it does for the top tier mirrors
18:37:06 <Oxf13> since downstream mirrors hit them a lot to get their data
18:37:18 <Oxf13> so staging events do have a significant impact on places like kernel.org
18:37:45 <poelcat> have they told us it is so significant we should not do it?
18:37:55 <Oxf13> kernel.org has requested that at least
18:39:33 <nirik> could we stage in a way that has less impact? Everything will land a lot earlyer.
18:39:54 <nirik> at f14 branch point right?
18:39:55 <Oxf13> nirik: not really, the isos are the big hit
18:40:04 <Oxf13> well
18:40:21 <Oxf13> 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 <nirik> but the isos are behind the bit flip? or they mean lower tiered official mirrors that sync that from them?
18:40:39 <Oxf13> 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 <Oxf13> 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 <Oxf13> nirik: no, I talked a bit to hpa and warthog about it.
18:42:39 <Oxf13> 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 <Oxf13> it would threaten our ability to have enough mirrors ready to open at release day
18:44:43 <poelcat> Oxf13: so you're set on 2 weeks... nothing else to consider or sway you?
18:45:11 <Oxf13> poelcat: enough -1 votes from other releng members.
18:45:38 <Oxf13> I just don't like planning for a situation where we have to fail in order to succeed
18:46:30 <poelcat> i would agree
18:48:26 <notting_> assumption: all dates move forward the same amount?
18:48:28 <poelcat> 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 <poelcat> notting_: my assumption was add two week to front of schedule and hold freeze lengths the same, etc.
18:49:11 <Oxf13> notting_: that's probably best to avoid another 2 weeks of fine tuning / arguing (:
18:49:37 <poelcat> so more devel time :)
18:50:47 <Oxf13> not the worst thing in the world.
18:53:02 <poelcat> http://poelstra.fedorapeople.org/schedules/f-13-draft/f-13-two-more.html
18:53:34 <Oxf13> #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 <Oxf13> +1
18:54:50 <Oxf13> lets get this voted on and approved
18:55:44 <poelcat> +1 with minor reservations
18:56:50 <notting_> 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 <Oxf13> notting_: I'm not thrilled either, but I think it'd be pretty shitty of us to ignore these requests
18:58:15 <rdieter> +1
18:59:23 <poelcat> Oxf13: so first response to mirror query was needing 7 days, not 2 weeks
18:59:29 <poelcat> if i understood it correctly
18:59:48 <Oxf13> poelcat: yea, he's likely a downstream mirror, not a tier1
19:00:06 <Oxf13> for downstream mirrors 7 days is likely fine.  For tier1, it isn't.
19:00:41 <Oxf13> tier1s would be trying to service users downloading Ubuntu, while at the same time trying to service tier2+ mirrors staging Fedora
19:02:43 <Oxf13> dgilmore jwb spot lmacken warren any of you have opinions on this matter?
19:03:01 <spot> i think you spent about 20 minutes more than necessary discussing it.
19:03:13 <spot> does that count as an opinion?
19:03:19 <jwb> i haven't paid attention for about 30 min, but i agreed with your 'i refuse to plan to fail'
19:03:31 <notting_> 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 <warren> I would prefer failing to plan.
19:03:52 <spot> notting_: no thanks, i'm going to go offline and be a dick.
19:04:16 <notting_> spot: wait, you're tom *and* dick? who's harry?
19:04:27 <spot> notting_: can't keep track these days.
19:04:38 <warren> 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 <Oxf13> notting_: I am, everywhere except for my head
19:04:54 <notting_> Oxf13: TMI.
19:05:28 <Oxf13> 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 <dgilmore> Oxf13: im ok with it
19:06:00 <dgilmore> +1
19:06:20 <Oxf13> Ok, I think that's enough votes
19:06:51 <Oxf13> #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 <Oxf13> #topic LXDE respin
19:07:16 <Oxf13> .fesco 280
19:07:17 <zodbot> 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 <Oxf13> ok, background
19:08:16 <notting_> chitlesh is FEL. cwickert is LXDE.
19:08:18 <Oxf13> LXDE spin was broken
19:08:23 <Oxf13> we pulled it
19:08:26 <dgilmore> opps my bad
19:08:34 <Oxf13> and now they have it fixed with one package update.
19:08:37 <dgilmore> cwickerts fedora people page
19:08:48 <Oxf13> 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 <cwickert> why that?
19:09:08 <Oxf13> 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 <Oxf13> and we don't have to worry about adding an srpm somewhere to be kept live until the torrent goes away
19:09:52 <cwickert> sorry, I don't get it. why has the srpm to be in the torrent?
19:10:00 <notting_> 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 <notting_> cwickert: if you pull in an update, that later gets obsoleted in updates/, where would the user get the corresponding source?
19:10:29 <cwickert> I see
19:10:37 <Oxf13> 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 <Oxf13> generally we do that by pointing to the Everything/ tree on the mirror
19:10:53 <cwickert> what about shipping the spin without the update?
19:10:54 <dgilmore> Oxf13: adding the srpm to the iso would be ok also
19:11:08 <Oxf13> cwickert: shipping the spin without the update would result in a broken spin
19:11:13 <cwickert> no
19:11:16 <Oxf13> dgilmore: it would, but that's a bit harder to do
19:11:25 <cwickert> the only reason to ship it is that update declared it as a secutiry update
19:11:34 <cwickert> see the discussion in bodhi
19:12:04 <cwickert> and I doubt it's really security sensitive
19:12:21 <cwickert> we can fix this with only with working around the crash in the spec
19:12:28 <Oxf13> "the spec" ?
19:12:30 <Oxf13> the spec of what?
19:12:33 <cwickert> sorry, ks
19:12:55 <nirik> so it just needs a ks change, no package change now?
19:13:24 <cwickert> right, I though that was from the ticket and the linked update
19:13:26 <Oxf13> by disabling the screensaver
19:13:41 <Oxf13> that change doesn't carry over to the installed image does it?
19:13:55 <cwickert> ?
19:14:12 <cwickert> no it doesn't , it's only on the livesystem
19:14:17 <nirik> cwickert: oh, sorry... got confused then. If we just need a ks change and no rpm change, thats fine.
19:14:29 <cwickert> on the other hand I don't want to ship a spin without  a known security problem
19:14:39 <notting_> with? :)
19:14:48 <cwickert> s/don't want/dislike
19:15:01 <cwickert> sorry notting, without the update, with the problem
19:15:09 <nirik> you mean the PK thing?
19:15:22 <cwickert> no
19:15:26 <cwickert> menu-cache
19:15:32 <Oxf13> doesn't look like a security thing to me
19:15:34 <cwickert> as linked in the ticket
19:15:45 <cwickert> not for me ether, but upstream says so
19:15:56 <Oxf13> did they file a CVE?
19:16:01 <cwickert> but he doesn't provide any details, not even in private mail
19:16:07 <notting_> wait a sec
19:16:21 <notting_> 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 <Oxf13> that's true
19:17:38 <Oxf13> seems FESCo already voted to ship with the update
19:17:47 <Oxf13> but that may have been under the assumption that the update was necessary to fix the problem
19:17:59 <nirik> yes, thats the way I read it.
19:18:15 <Oxf13> that's the way it reads to me too :/
19:18:17 <nirik> 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 <nirik> not that it's some incidental security update.
19:18:41 <nirik> which link?
19:18:53 <Oxf13> 'menu-cache-0.2.6 update' is a link to bodhi
19:19:06 <Oxf13> with details:
19:19:07 <Oxf13> 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 <nirik> 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 <Oxf13> 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 <notting_> which probably should be noted in the ticket for consideration, and then discussed at the fesco level (not here)
19:20:06 <cwickert> sorry if it was unclear
19:20:10 <Oxf13> 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 <cwickert> 'back to'? there was no fesco decision so far
19:20:59 <Oxf13> #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 <Oxf13> cwickert: there were enough votes on the ticket to approve it
19:21:22 <cwickert> ok, I see
19:21:53 <Oxf13> #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 <Oxf13> I'm +1 on that idea.
19:22:10 <notting_> oops, i already updated the ticket
19:22:12 <Oxf13> cwickert: if it goes fast enough, I can still get it spun up today
19:22:20 <Oxf13> notting_: I'll take that as a +1 then (:
19:22:48 <notting_> 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 <notting_> if that makes sense
19:22:55 <cwickert> 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 <cwickert> Oxf13: that would eb great
19:23:15 <dgilmore> Oxf13: as long as the installed system is ok then im +1
19:23:20 <cwickert> it is
19:23:26 <cwickert> no changes to the packages
19:24:12 <dgilmore> 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 <cwickert> 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 <dgilmore> 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 <Oxf13> dgilmore: the basic problem only occurs in the live environment
19:25:10 <cwickert> "no changes to the packages" means no change to the installed system
19:25:11 <Oxf13> dgilmore: it does not occur if you do an LXDE installation
19:25:18 <dgilmore> Oxf13: ok
19:25:25 <cwickert> right, the installed system had no crash at all
19:27:37 <nirik> the more changes we make the higher the chance some security update messes up something else.
19:27:52 <nirik> 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 <Oxf13> yeah
19:29:12 <Oxf13> #agreed LXDE respin decision kicked back up to FESCo in light of new information.
19:29:18 <Oxf13> #topic Updates
19:29:23 <Oxf13> jwb: you have the floor
19:29:52 <jwb> so a couple of quick items
19:30:02 <jwb> 1) last f10 updates push is dec 11
19:30:09 <jwb> i sent this to f-d-a
19:30:43 <jwb> 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 <jwb> but i have no idea what it's doing to the koji storage
19:31:22 <Oxf13> We may have to adjust our garbage collection wrt signed packages.
19:31:29 <Oxf13> but we needed to revisit that anyway
19:32:00 <jwb> 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 <Oxf13> right
19:34:59 <Oxf13> jwb: anything else on updates?
19:35:19 <jwb> nope, that was it.  looking forward to push times going down temporarily with f10 dying
19:35:53 <Oxf13> whee!
19:40:29 <Oxf13> #topic open floor
19:40:36 <Oxf13> anybody got anything? We're 40 minutes over :/
19:40:56 * notting_ does not
19:45:31 <Oxf13> #endmeeting