[02:33] <micahg> does a new binary package (-dbg) need a freeze exception?
[03:17] <ScottK> Yes.
[03:18] <micahg> thanks
[11:08] <skaet> cjwatson, good morning, on the daily CD report, there are a lot of amd64 packages suddenly producing uninstallable binaries.  Is root cause known?
[11:19] <cjwatson> skaet: those are usually transient; I haven't checked in this case
[11:20]  * cjwatson runs daily-checks --stdout since he's deleted that mail
[11:23] <skaet> cjwatson,  :) have forwarded the email to you.   Will be curious to see what the current daily-checks produces and compare.
[11:23] <cjwatson> skaet: webkit built a bit sooner on amd64 than on i386 (https://launchpad.net/ubuntu/+source/webkit/1.4.3-0ubuntu1), and libwebkitgtk-1.0-0 depended on a newer libwebkitgtk-1.0-common which is architecture-independent and only built on i386
[11:23] <cjwatson> skaet: didn't need a forward :)
[11:24] <cjwatson> the current daily-checks says nothing different because CDs haven't rebuilt
[11:24] <cjwatson> skaet: anyway, it was transient and will go away with the next build
[11:24] <skaet> cjwatson, coolio.  That makes sense.   Thanks!
[11:25] <cjwatson> FWIW I normally don't worry much about single-architecture spikes in the output unless (a) we're almost at a milestone or (b) they persist for more than one day
[11:25] <skaet> thanks.   Will keep that in mind.
[11:25] <cjwatson> unless both amd64 and i386 fail, in which case it's probably a real problem
[11:26]  * skaet nods
[11:26] <cjwatson> ha!  fix for the grotty octave-symbolic NBS coming up.
[12:30] <jamespage> please could I get a release team OK for https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/844745
[12:30] <ubot4> Launchpad bug 844745 in tomcat7 (Ubuntu) "[FFE] Sync tomcat7 7.0.21-1 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Wishlist,New]
[12:30] <jamespage> ta
[12:59] <jdstrand> if someone could ping me on ^, I'll do the sync
[13:35] <ScottK> Great.
[15:07] <Laney> How is it decided which bugs are milestoned?
=== lan3y is now known as Laney
[15:13] <Laney> .
[15:19] <ScottK> I developer decides it should be milestoned and does it.
[15:19] <ScottK> I/A
[15:23] <Laney> OK, didn't know if it needed Official Seals of Approval or anything. Ta.
[15:26] <Laney> how come we don't have a beta freeze for B2?
[15:26] <cjwatson> isn't that within final freeze?
[15:26] <cjwatson> oh, huh, no, that got moved
[15:27] <cjwatson> um
[15:27] <cjwatson> skaet: ^-- we probably ought to have at least a few days there
[15:28] <Laney> 15th would be in line with B1
[15:28] <Laney> but that's rather close to now I guess
[15:29] <cjwatson> things should be slowing down anyway ...
[15:34] <skaet> cjwatson, Laney - hmm,  that's an oversight, the intention was that it would be 1 week before B2 (ie. 15th).   I'll clarify that in the release meeting tomorrow.
[15:35] <Laney> Adding it to the wiki and letting people know would be a good idea.
[15:35] <seb128> skaet, cjwatson, pitti: GNOME 3.1.92 is on the 19th
[15:35] <seb128> would that still be ok to get in beta2?
[15:38] <skaet> seb128,  ouch, that timing is too tight.   Probably not, unless everything else is looking smooth.
[15:39] <seb128> skaet, ok, it means we will have to deal with the 3 weeks of bug fixes to land after beta2
[15:39] <seb128> and test non current versions
[15:39] <seb128> which is a bit of a shame...
[15:39] <seb128> like most beta-2 bug will probably be useless for GNOME
[15:41] <skaet> seb128,  hmm.   good points, any way the bug fixes applied up til beta freeze can get cherry picked in?  (ie. pull in the candidate for 3.1.92?)
[15:42] <skaet> any down sides?
[15:42] <seb128> we could
[15:42] <seb128> it just mean we would have to cherry pick some hundred commits
[15:42] <seb128> it's weeks of work
[15:43] <seb128> or we can probably git snapshot half of GNOME next week
[15:43] <seb128> to update again after beta2
[15:43] <seb128> knowing that I'm on holidays next week so let's see what the other guys can do
[15:45] <skaet> seb128,   ok, lets see if someone can pick up the snapshot,  otherwise, lets see where we are on the 19th.
[15:46] <charlie-tca> I wonder how much of Xubuntu those gnome upgrades will break this late?
[15:46] <skaet> Am worried about not having enough time to recover if there is an interaction with other components,  so close to the beta2.   On monday we should have the first set of candidate images, and if they're usable, maybe look at taking the risk.
[15:48] <seb128> skaet, well, GNOME is feature frozen, ui and string frozen
=== bdmurray_ is now known as bdmurray
[15:48] <seb128> skaet, so those updates will just be some weeks of bug fixing
[15:50] <seb128> we really need to revisit the schedule next cycle to have something which work compared to GNOME, if we can't get .92 in beta2 it will cost us on beta2 quality and usefulness of the feedback we will get since the bugs that we will receive might be fixed already and we will miss new ones
[15:50] <skaet> seb128,  understood, but if there are 100's of commits coming in, unexpected interactions from someone's fix, with someone else's workaround might occur.
[15:51] <skaet> ie. one of the gnome fixes, might snag up one of the interfacing components.   May not, but may.
[15:53] <ScottK> Right, but is it better to find that out before beta 1 or after?
[15:54] <skaet> ScottK,  Very much would like it before, but don't want to risk not having images we can ship either.   And this could be an image breaker/non recoverable.
[15:55] <ScottK> IIRC it doesn't take that long to get a Gnome release built.
[15:55] <ScottK> I think there should still be time to manage.
[15:58] <seb128> we would get things in and built on monday
[15:58] <skaet> If .92 lands on monday,  it will get built into images on Monday night.  Issues will be noticed on Tuesday testing, interaction debugging could be ??.  Last set of fixes would need to be figured on on Wednesday for those affected, and put into builds on Wednesday night and tested Thurs morning.  It would be a repeat of the Beta 1 cycle.
[15:59] <seb128> we did that for quite some cycles, it usually works fine since GNOME freezes tend to be solid and the updates at the end of the cycle stable
[15:59] <seb128> well, other option is to wait after beta2
[15:59] <seb128> we will not likely update GNOME on a friday
[15:59] <seb128> which means we would start testing those one week later
[16:00] <seb128> and get non useful feedback from beta2
[16:00] <ScottK> Then if there's problems you've lost a week and upstream says "You were using an old version, try again"
[16:00] <seb128> then we need to test the new version, get feedback on those, start seing issue
[16:00] <dblawson> I'm putting the buildd's on manual for a package bootstrap
[16:00] <skaet> If we have a fall back set of images created on monday morning that test out okay - we could look consider it.
[16:00] <seb128> we loose a good 10 days of work if we go this way
[16:01] <ScottK> dblawson: You aren't killing existing builds are you?
[16:01] <dblawson> ScottK: Nope
[16:01] <skaet> seb128,  we could get much of the same benefit though by taking a snapshot, and then refreshing too though.
[16:01] <ScottK> OK.  Good.
[16:01] <ScottK> skaet: Not really.  You still end up with upstream telling you to retry with the current version.
[16:02] <Laney> For useful testing, you really want people to be running the latest version
=== shadeslayer_ is now known as shadeslayer
[16:04] <skaet> the current version will be in the daily images on the 23rd,  so we'll see pretty quickly, if the issue is there.
[16:06] <seb128> skaet, yeah, out of the fact that rather than packaging the tarballs they will test and roll we will have to do snapshots ourselves next week
[16:06] <seb128> but as I'm not sure next week so I will let pitti and other decide and see what they can do
[16:07] <skaet> I do understand your points though.   Want to do some more digging to see if there are some options to increase the likelyhood of shippable images.   Lets revisit tomorrow at the end release meeting.
[16:07] <seb128> ok
[16:07] <pitti> skaet: we could also update the apps on monday (which wouldn't lead to complete image failures), and do snapshots of the base libs like glib/gtk before
[16:07] <skaet> thanks for bringing it up seb128.   Very much appreciate it being on the radar now, rather than on the 19th ;)
[16:08] <Laney> it would be good to have a calendar that shows all major upstream cycles for products on the images
[16:08] <skaet> pitti,  yeah something like that might be worth trying.
[16:09] <pitti> GNOME and KDE release are special enough for us to justify adding it to our existing release interlock pages?
[16:10] <skaet> Laney, https://wiki.ubuntu.com/OneiricReleaseInterlock
[16:10] <skaet> pitti, yeah,  I think we shold add them to the interlock page.
[16:10] <Laney> skaet: yes, like that but with upstreams
[16:10] <skaet> Laney - last column.
[16:10] <micahg> skaet: do you want the same for Mozilla now that they have a schedule?
[16:10] <Laney> doesn't look particularly complete
[16:10] <Laney> only shows gnome final for example
[16:11] <skaet> micahg,  adding in Mozilla on the interlocks would be good.
[16:11] <dblawson> Done, buildd's are back to auto
[16:11] <micahg> chrisccoulson: ^^ could you handle that
[16:12] <skaet> Laney,  yeah its not as complete as it should be,  but if we get in the habit of adding them, it makes it easier to remember to look for them for the next cycle too.
[16:13]  * skaet encourages everyone who is aware of an upstream date that's significant to add it there. 
[16:14] <ScottK> Given the early October release date, the last KDE date of significance was probably last Monday, but I'm double checking.
[16:15] <ScottK> Err, Tuesday.
[16:17] <skaet> thanks ScottK
[17:16] <chrisccoulson> am i ok to edit https://wiki.ubuntu.com/OneiricReleaseInterlock then, to add the Mozilla dates
[17:16] <chrisccoulson> ?
[17:29] <micahg> chrisccoulson: yeah, skaet said that was a good idea
[17:32] <ScottK> skaet: I added the KDE 4.7 dates to the Oneiric interlock schedule.  Ask expected, release is a week too early for us to get 4.7.2.
[17:34] <chrisccoulson> pk, done
[17:34] <chrisccoulson> **ok
[17:34] <ScottK> skaet: Here's the link for KDE 4.8 to use for planning for "P".  It would be REALLY nice to be able to get 4.8.2 in at relase, which would require release April 19 or the next week.
[17:34] <ScottK> http://techbase.kde.org/Schedules/KDE4/4.8_Release_Schedule
[17:34] <chrisccoulson> skaet, if you ping me when you have a P equivalent of https://wiki.ubuntu.com/OneiricReleaseInterlock, then I can give you the next 6 months of Mozilla release dates ;)
[17:37] <skaet> Thanks for adding them ScottK.    Will be doing a scrub on the P schedule early next week,  then cloning it into the PReleaseInterlock, so seeing how things lay out will help with tuning.
[17:37] <skaet> chrisccoulson, will do.  :)   Thanks
[17:56] <stgraber> skaet: hi! bug 575469 has been targeted for beta2. I now have a fix for it but it's a pretty substential change to friendly-recovery and minimal changes to a bunch of other packages.
[17:56] <ubot4> Launchpad bug 575469 in newt (Ubuntu Oneiric) (and 3 other projects) "[UIFe] [FFe] recovery mode mounts filesystems read-write rather than read-only (affects: 2) (heat: 12)" [Undecided,Invalid] https://launchpad.net/bugs/575469
[17:56] <stgraber> skaet: I'm currently waiting for some reviews of the changes before actually subscribing ubuntu-release for the exceptions
[18:01] <skaet> stgraber, thanks for the head's up.   Yeah,  lets make sure the other component reviewers are happy before this lands.  Timing is ok as long as the others affected are comfortable with the changes.
=== joshuahoover1 is now known as joshuahoover
[18:13] <utlemming> Hi, can I have a reviewer approve a byobu change that fixes https://bugs.launchpad.net/ubuntu/+source/byobu/+bug/844994?
[18:13] <ubot4> Launchpad bug 844994 in byobu (Ubuntu Oneiric) (and 1 other project) "byobu initialization is slow KVM cloud-images (affects: 1) (heat: 6)" [High,Fix committed]
[18:17] <ScottK> utlemming: It's a bugfix, so no release team review is needed.
[18:18] <ScottK> Talk to kirkland about when he plans to upload it.
[18:19] <utlemming> Scott: okay, thank you kindly
[18:22] <kirkland> utlemming: thanks, will upload shortly