Started logging meeting in #ubuntu-meeting
[10:02:33] <Riddell> hi
[10:02:49] <skaet> hi Riddell
[10:02:55] <skaet> purpose of this meeting is to improve coordination between teams on the stable release (and long term support) long term support updates.
[10:03:09] <skaet> meeting agenda is at: https://wiki.ubuntu.com/ReleaseTeam/Meeting/StableReleaseAgenda
[10:03:23] <skaet> ts a symbolic link, and will always point to the latest. I'll be updating it, with minutes from today's meeting, and we'll adapt it in future, as these meetings evolve
[10:03:35] <skaet> seem reasonable?
[10:03:48] <sconklin> ack
[10:03:55] <skaet> Would like to briefly go through some of the bugs on the radar for the 10.04.2 LTS, then move on to discussing the SRU kernel bi-weekly release, then to general SRU updates.
[10:04:45] <zul> hi
[10:04:57] <skaet> hi zul
[10:05:11] <skaet> for 10.04.2 any update on the kernel bug flagged?
[10:05:47] <skaet> Bug #635344 - should it be resolved by an SRU update before, or be part of the 10.04.2?
[10:05:48] <ubottu> Launchpad bug 635344 in linux (Ubuntu Lucid) "After my CD-Rom is ejected, the tray will instantly retract." [High,Confirmed] https://launchpad.net/bugs/635344
[10:06:30] <skaet> sconklin?
[10:06:38] <sconklin> waiting for launchpad
[10:06:47] <skaet> thanks
[10:06:48] <cjwatson> wuh?
[10:07:04] <pitti> that sounds like an ancient udev cdrom_id issue all over again
[10:07:15] <skaet> cjwatson, there's a few in the foundations list as well for 10.04.2
[10:07:21] <pitti> but the main problem there already got fixed years ago, ceratinly much earlier than lucid
[10:07:21] <cjwatson> hang on
[10:07:27] <sconklin> it's not clear that this is even a kernel bug, we have many bugs more worthy that this one, and there's no known fix, so not sure why it's on the list
[10:07:27] <cjwatson> waiting for launchpad to do what?
[10:07:53] <sconklin> should have written "no fix described in the bug wrt the kernel"
[10:08:11] <cjwatson> oh, right, waiting for launchpad to return the page :-)
[10:08:15] <skaet> sconlkin, okie. lets just get it statused correctly.
[10:08:18] <sconklin> I was waiting for launchpad to serve the bug page
[10:08:22] <skaet> :)
[10:08:49] <sconklin> ..
[10:08:52] <cjwatson> skaet: bug 563916 and bug 607657 should definitely be RC for 10.04.2, and are on my list
[10:08:55] <ubottu> Launchpad bug 563916 in plymouth (Ubuntu Lucid) "[details.so] No prompt for [S]kip or [M]anual recovery on server boot (or without "splash")" [High,Confirmed] https://launchpad.net/bugs/563916
[10:08:56] <ubottu> Launchpad bug 607657 in base-installer (Ubuntu Lucid) "Lucid point release installer must support LTS backported Kernels" [High,Triaged] https://launchpad.net/bugs/607657
[10:09:11] <cjwatson> skaet: I asked ev to look at bug 591207 for .1, but it didn't work out, will go round on that again - it's a messy bug
[10:09:13] <ubottu> Launchpad bug 591207 in casper (Ubuntu Lucid) "Casper's USB update-initramfs shim should look for initrd.img in /boot" [High,Confirmed] https://launchpad.net/bugs/591207
[10:09:27] <cjwatson> skaet: I confess to having no idea about bug 635273 just now
[10:09:28] <ubottu> Launchpad bug 635273 in python-support (Ubuntu Lucid) "Building debs with SWIG libraries do not work" [High,Confirmed] https://launchpad.net/bugs/635273
[10:09:51] <cjwatson> build tool changes scare me slightly in a point release though
[10:10:16] <cjwatson> it may be less dangerous to leave this broken
[10:10:18] <skaet> cjwatson, thanks! ok, we'll keep tracking these.
[10:10:22] <cjwatson> ScottK: ^- you might disagree though
[10:11:29] <skaet> do we have anyone from server team? there's bug #671103
[10:11:33] <ubottu> Launchpad bug 671103 in cloud-init (Ubuntu Lucid) "backport grub-legacy-ec2 from maverick to lucid" [High,Fix committed] https://launchpad.net/bugs/671103
[10:11:51] <cjwatson> that got accepted for validation earlier today
[10:12:08] <skaet> heh, ok, didn't spot it in the morning scans. :)
[10:13:10] <skaet> pitti, how about the bugs against desktop? bug # 525807, bug #459647, bug #625280
[10:13:13] <ubottu> Launchpad bug 459647 in compiz (Ubuntu Lucid) "Cannot change mouse cursor theme when compiz is enabled" [Medium,Triaged] https://launchpad.net/bugs/459647
[10:13:14] <ubottu> Launchpad bug 625280 in xserver-xorg-video-geode (Ubuntu) "SRU: xserver-xorg-video-geode 2.11.9-1 to Lucid and older supported releases" [High,In progress] https://launchpad.net/bugs/625280
[10:13:40] <pitti> skaet: 459647/compiz has been going on and off, and is a problem when running compiz under KDE
[10:13:48] <skaet> ack
[10:13:54] <skaet> will keep on list then
[10:13:55] <pitti> we already had an attempted fix, but it caused regressions and was pulled
[10:14:10] <pitti> I wouldn't count on it for .2, and I think at this point we should just declare it broken in lucid
[10:14:17] <pitti> instead of jeopardizing stability
[10:14:28] <pitti> -geode> fairly recent request; I think it will go through
[10:14:34] <skaet> ok
[10:14:36] <pitti> so definitively keep geode on the list
[10:14:51] <pitti> wrt bug 525807
[10:14:52] <ubottu> Launchpad bug 525807 in openoffice.org (Ubuntu Lucid) "[upstream] [3.2.1] OOo Slide Show and Fullscreen modes - not full screen under compiz" [Medium,In progress] https://launchpad.net/bugs/525807
[10:15:10] <pitti> we backported 3.2.1 to lucid-proposed, but there was one regression report, which kept that from flowing to -udpdates
[10:15:25] <pitti> we have been looking for an OO.o maintainer for a while now, and are interviewing
[10:15:40] <pitti> but since we don't currently have an OO.o maintainer, I'd drop this from the 10.04.2 list
[10:15:53] <pitti> (sorry about that)
[10:16:06] <skaet> hmm, still a bit of time for 10.04.2 - so will keep it on the list until jan
[10:16:11] <pitti> but neither the original bug nor the regression are even close to "easy"
[10:16:19] * skaet hoping we get an OO.o maintainer hired soon ;)
[10:16:28] <pitti> skaet: me too :)
[10:16:36] <skaet> :)
[10:17:05] <skaet> ok, that pretty much wraps up what was on my radar for 10.04.2, anyone have anything to raise as a "to be watched"?
[10:18:02] <skaet> [TOPIC] Stable Release Update
[10:18:24] <cjwatson> just sponsored bug 671097, which I know the server team wants
[10:18:26] <ubottu> Launchpad bug 671097 in grub2 (Ubuntu Lucid) "update-grub needs to ignore linux-ec2 kernels" [Medium,Triaged] https://launchpad.net/bugs/671097
[10:18:26] <skaet> sconklin, where are we in this kernel cycle?
[10:18:32] <cjwatson> (and belatedly milestoned it)
[10:18:38] <skaet> cjwatson, :)
[10:18:54] <cjwatson> I sort of hate to bring it up because it's a mess of a bug, but bug 642555 is its usual nasty self
[10:18:55] <sconklin> If you look at the new stable cadence wiki page, I've renamed the cycle parts
[10:18:55] <ubottu> Launchpad bug 642555 in Ubuntu Lucid "Services not starting on boot in 10.04.1 LTS" [Medium,Confirmed] https://launchpad.net/bugs/642555
[10:19:11] <sconklin> instead of week1 week2, it's now verification phase and testing phase
[10:19:22] <skaet> cjwatson, rather know about the messes. thanks.
[10:19:22] <sconklin> since we may not always get the one week time periods
[10:19:25] <cjwatson> there's lots of complex history in the referenced bug 554172
[10:19:27] <ubottu> Launchpad bug 554172 in linux (Ubuntu) "system services using "console output" not starting at boot" [High,Confirmed] https://launchpad.net/bugs/554172
[10:19:36] <sconklin> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
[10:19:46] <sconklin> cjwatson: go ahead
[10:20:00] <cjwatson> sorry, I didn't mean to interrupt
[10:20:20] <skaet> no worries, its a first meeting, and we have some cadence to figure out, go ahead
[10:20:38] <skaet> signal you're done with .. though ok
[10:21:29] <sconklin> looking at that bug
[10:21:41] <cjwatson> I don't think we know a good fix for this one, and the same kernel maybe-bug caused a mess in consolekit too (since worked around), but I don't think it's likely that we can improve the kernel here; apw already spent quite a while looking at this
[10:22:11] <cjwatson> my gut feel is that we should do something like having upstart (internally?) try a few times to get a console fd, and emit some kind of event when it's done
[10:22:31] <cjwatson> I'll need to talk about it with Keybuk/azul though
[10:22:34] <sconklin> oh, this could be related to the tty race condition that could be fixed with a change to upstrart, which was rejected as inelegant.
[10:22:37] <sconklin> If memory serves
[10:22:43] <cjwatson> Keybuk *did* change upstart!
[10:22:47] <cjwatson> as a point of information
[10:22:58] <apw> cjwatson, there is supposed to be more work coming from upstream which will close the races markedly, though i have not looked to see how much of that is in what is in natty
[10:23:03] <sconklin> ok, thanks for correcting that
[10:23:15] <cjwatson> however the change was to redirect the console to /dev/null if we lost the race
[10:23:23] <cjwatson> so at least we boot now, but we get this bug
[10:23:39] <Keybuk> right, and the opposite problem applies to Upstart
[10:23:47] <Keybuk> if Upstart is infinite-looping (or event-ing) when a console is ready
[10:23:56] <Keybuk> then you may never start the job that causes the console to be created
[10:23:57] <cjwatson> what I did in consolekit was to sleep for a bit until a console fd arrived, if we got EIO
[10:24:00] <Keybuk> because that needs a console
[10:24:00] <Keybuk> etc.
[10:24:17] <cjwatson> but I don't think that would work in upstart quite so obviously
[10:24:29] <apw> cjwatson, that is the 'approved' upstream solution to the issue
[10:25:09] <cjwatson> Keybuk: indeed, so it would need to be "try for a while, and then /dev/null"
[10:25:18] <cjwatson> rather than "/dev/null immediately"
[10:26:09] <Keybuk> I don't like the "for a while" in init ;-)
[10:26:12] <cjwatson> anyway, had intended to talk to you out-of-meeting about it rather than having the technical argument here :)
[10:26:33] <apw> (wednesday might be appropriate)
[10:26:42] <cjwatson> what's on Wednesday?
[10:26:57] <pitti> the upstart tech talk
[10:26:59] <apw> Keybuk's master class on upstart
[10:27:16] <Keybuk> well, I wouldn't want to spend the opportunity only talking about console devices
[10:27:31] <Keybuk> which is more "init covering up for the kernel's shortcomings"
[10:27:58] <cjwatson> not really the right forum, indeed
[10:28:02] <skaet> ok, how about an action item to track this discussion offline, and turn it back sconklin.
[10:28:38] <sconklin> so - aside from renaming the stable cadence parts:
[10:28:54] <sconklin> https://wiki.ubuntu.com/Kernel/StableReleaseCadence
[10:29:12] <sconklin> we're now in the "testing phase" for both maverick and lucid
[10:29:25] <sconklin> Lucid has completed cert testing, and no word on regression testing.
[10:29:50] <sconklin> I heard from Victor Friday that he had completed cert testing for Lucid in about a day, nice work!
[10:29:50] <apw> sconklin, which flavours and which architectures are tested for lucid
[10:30:05] <sconklin> victorp: ??
[10:30:06] <victorp> apw - is Ubuntu
[10:30:12] <victorp> for netbooks
[10:30:27] <victorp> desktop edition (laptops and pc_
[10:30:29] <victorp> servers
[10:30:46] <victorp> need to double check but edition I think includes x32 x64
[10:30:58] <victorp> so the same ones that we certify
[10:31:04] <sconklin> victorp: is there a place where testing results are publiched?
[10:31:10] <victorp> apw - no other Ubuntu flavours at the mo
[10:31:10] <sconklin> (This is later in the agenda)
[10:31:17] <skaet> victorp, is there an online report/summary of testing?
[10:31:20] <victorp> yes but is not permanent
[10:31:37] <victorp> cr3 is going to add a copy to the bug as you suggested
[10:31:56] <victorp> http://people.canonical.com/~cr3/hw-testing/lucid-proposed.html
[10:32:24] <sconklin> would be nice to have arch added to that report
[10:32:45] <sconklin> what's the status of cert testing for Maverick?
[10:33:40] <sconklin> victorp: ?
[10:34:40] <sconklin> ok, while we're waiting for that, what's the status of regression testing for Lucid or Maverick?
[10:35:15] <sconklin> tumbleweeds
[10:35:17] <skaet> pedro?
[10:35:19] <victorp> maverick
[10:35:39] <victorp> we just started today
[10:35:49] <victorp> so I hope to have everything done tomorrow
[10:35:56] <sconklin> victorp: excellent, thanks
[10:35:59] <victorp> (done_
[10:36:02] <pedro_> we've been running the qa-regression-testing suite on VM's at the moment but we're waiting for real HW or move it to the HW cert lab to have more coverage
[10:36:08] <skaet> pedro, jibel, has there been any regression testing figured out for kernel SRU?
[10:36:22] * skaet too slow on typing - thanks pedro_
[10:36:39] <victorp> pedro_ can you not run that via checkbox ?
[10:36:49] <victorp> pedro_ on hw in the lab?
[10:37:18] <pedro_> victorp, we need to talk with cr3 to know if that's possible or not
[10:37:48] <victorp> pedro_ ?
[10:37:51] <sconklin> Should we hold these kernels until we get definitive regression testing, or hold that cert testing is 'good enough'?
[10:37:54] <pedro_> but the perfect solution would be to include the qa-regression-testing suite into checkbox and run the tests on the same machines at the HW cert lab
[10:37:54] <skaet> pedro_, any reservations about lucid going out?
[10:38:30] <pedro_> that way you'd have more coverage and better chances to catch regressions
[10:38:46] <victorp> pedro_ that doesnt make sense to me
[10:39:15] <vanhoof> sconklin: victorp: the maverick sru is of top priority for the hwe team
[10:39:23] <victorp> pedro_ if that is the perfect solution , what is stopping us from doing it. You can have the HW that you need, so just run them. no?
[10:39:23] <pedro_> skaet, not really
[10:39:52] <skaet> pedro_, ok. lets consider that good for now, and work on the regression flow incorporated for next 2 week cadence.
[10:39:58] <victorp> vanhoof ack
[10:40:02] <pedro_> victorp, as said, we need to talk with cr3 to know if that could be included on checkbox or not and the best way to do it
[10:40:05] <sconklin> I'd like to not be in an indefinite hold on these, and cert testing is more than we have had in the past. Can we even get a firm commitment for regressions testing time frame?
[10:40:12] <pedro_> victorp, he's the expert, so better to talk with him about it
[10:40:40] <skaet> sconklin, go with lucid right now, and based on tomorrows results from maverick make a decision then?
[10:40:47] <victorp> sconklin - I agree
[10:41:04] <sconklin> Since we're talking about infrastructure questions, I think the answer to my question is no - we have no firm time frame, and I vote for shipping it
[10:41:26] <victorp> sconklin - +1
[10:41:29] <pitti> the old approach was to just leave it in proposed for 3 or 4 weeks and hoping for the best that we get told about regressions from the community
[10:41:46] <pitti> we can do that again for this round, of course
[10:42:02] <skaet> sconklin +1
[10:42:09] <sconklin> pitti: given that we'e been through the verification and cert testing, how do you feel about releasing Lucid now?
[10:42:13] <victorp> pitti - or until the next security update bumps the baking window
[10:42:33] <sconklin> It's effectively been in -proposed since UDS, except for the verification reverts
[10:42:48] <pitti> sconklin: it's only 5 days, and there are tons of changes
[10:42:55] <pitti> "now" seems exceptionally bold to me TBH
[10:43:34] <skaet> victorp, pitti - would like to get lucid out now, if its gone through cert, and get something out.
[10:43:37] <pitti> how about next monday? this gives us another week at least
[10:43:37] <sconklin> The agreement for the new process was that reverts due to lack of verification would not reset the -proposed bake time
[10:43:38] <bjf> pitti, the kernel changes that have been cooking for 5 days are just because of the reverts
[10:43:47] <vanhoof> pitti: this has been the same kernel (minus reverts) since ~Oct 20th
[10:44:00] <vanhoof> .37 was the first upload w/ this patchse
[10:44:01] <pitti> I see
[10:44:10] <vanhoof> *set
[10:44:29] <victorp> skaet _ I am in favour of going out, rather than wait for a community test that we dont know if it is happening
[10:44:32] <pitti> well, I can't say that I'm feeling good about it; I just wanted to say so, but if everyone else wants to push those out, then *shrug*
[10:44:54] <pitti> victorp: that's the precise attitude I do _not_ want us to get in to
[10:45:02] <pitti> "release it anyway, regardless of feedback"
[10:45:16] <victorp> pitti -?
[10:45:17] <pitti> (I know that we did test it on some machines in QA)
[10:45:39] <pitti> anyway, let's not bring that discussion up again, we had it at UDS
[10:45:44] <skaet> pitti, it has had a lot of tire kicking in the hw cert lab at least, and we did have the prior window.
[10:46:00] <pitti> skaet: right, I didn't say that we didn't get feedback on this one
[10:46:16] <skaet> pitti, ack. ok, we ship lucid. maverick tbd.
[10:46:18] <pitti> just about "I am in favour of going out, rather than wait for a community test"
[10:46:23] <pitti> it's a slippery slope
[10:46:33] <skaet> pitti, indeed. we're feeling our way here.
[10:46:47] <victorp> pitti you missed -- that we dont know if it is happening
[10:46:52] <sconklin> I will say that I will feel better when we have the additional testing, but for now, I think this is the best we can do. And - we've had weeks of community tests, and one week of testing since the reverts
[10:47:03] <pitti> victorp: right; my point exactly :)
[10:47:18] <skaet> so, since sconklins out tomorrow, who wants to be part of go/no go decision?
[10:47:23] <pitti> for the record -- I don't think that this is the best we can do
[10:47:26] <pitti> but I give in
[10:47:29] <skaet> for maverick.
[10:47:53] <sconklin> ok, who will update the tracking bugs for Lucid to verified?
[10:47:57] <bjf> i can make the call for the kernel sru team
[10:48:00] <sconklin> as a matter of process?
[10:48:03] <victorp> pitti - nevermind, that is not what I meant. As you said we talk about this at UDS at length. lets move on
[10:48:03] <bjf> skaet, ^
[10:48:18] <pitti> sconklin: I think we spoke about having a kind of "QA regression testing feedback bug" per upload, right?
[10:48:18] <vanhoof> just to confirm, the only remaining piece to the puzzle for maverick is cert testing of the -proposed kernel, yeah?
[10:48:35] <pitti> sconklin: does that exist for lucid? I guess that's the one we should flip to v-done then?
[10:48:38] <sconklin> pitti: there is one for each of maverick and lucid
[10:48:50] <pitti> good
[10:48:57] <skaet> pedro_, can you scan through the verified bugs for lucid are all reasonable at this stage?
[10:49:00] <sconklin> stand by and I'll find the bugs - Not sure whether they made the changelog
[10:49:25] <pedro_> skaet, yes, i'll have a look to those and report back to you
[10:49:52] <skaet> pedro, thanks, will give you and sconklin an action here.
[10:50:19] <skaet> to make sure that the bugs for maverick and lucid have been verified.
[10:50:30] <sconklin> Lucid testing tracking bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/677038
[10:50:48] <sconklin> Maverick: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/677021
[10:51:09] <skaet> bjf, thanks - will get together with you and victorp tomorrow morning and see where we are with maverick. pitti, can you join us if I set up a meeting?
[10:51:14] <victorp> I see lucid has already the hwcert test on it
[10:51:38] <victorp> skaet - morning , US time?
[10:51:51] <pitti> skaet: I have desktop team meeting at 1630 UTC, before that is fine
[10:52:07] <skaet> victorp, pitti - will aim for that window.
[10:52:17] <victorp> skaet - 3pm UTC is the HW Cert scrum
[10:52:34] <victorp> that needs to happen so I can give you an update
[10:52:39] <pitti> sconklin: I subscribed ubuntu-sru to 677038; it wasn't liked to the changelog, nor u-sru subscribed, so I didn't see it
[10:52:40] <skaet> [ACTION] skaet to set up meeting on maverick
[10:53:13] <sconklin> that's all I have on the SRU kernels
[10:53:14] <sconklin> ..
[10:53:15] <skaet> [TOPIC] general SRU
[10:53:36] <pitti> sconklin: what do we do about -ec2, dove, etc?
[10:53:46] <skaet> there are lots of questions here, can all take an action to go through, and come back on next meeting.
[10:54:14] <pitti> sconklin, cjwatson: oh, and we need a d-i rebuild against -26
[10:54:30] <pitti> seems the current one in -proposed is against -25
[10:54:48] <cjwatson> can be done
[10:55:10] <skaet> zul - what is the server SRU report that should be used? I found two of them?
[10:55:21] <sconklin> pitti: -ec2, mvl-dove have not been well discussed, and need to be
[10:55:26] <cjwatson> any chance of the current debian-installer going into -updates first though?
[10:55:35] <zul> skaet: hi...this is the one we use
[10:55:36] <pitti> cjwatson: yes, it's verified
[10:55:36] <cjwatson> the current images in -updates are broken
[10:55:42] * skaet is planning at ending this at the hour... so we're in our 5 minute count down. ;)
[10:55:47] <pitti> just need to do that publishing exercise
[10:55:49] <zul> skaet: http://people.canonical.com/~chucks/SRUTracker/sru-tracker-bugs.html
[10:55:50] <cjwatson> I can do that
[10:55:53] <pitti> cjwatson: thanks
[10:55:54] <skaet> zul, thanks.
[10:55:57] <cjwatson> since I think I wrote the procedure :)
[10:55:59] * pitti needs to leave in 3 mins, too
[10:56:19] <zul> skaet: the other one is really really old
[10:56:25] <skaet> any other questions? here's the other actions I've noted.
[10:56:38] <skaet> [ACTION] cjwatson, apw, Keybuk, azul - to come up with resolution on upstart interaction and bug 554172
[10:56:38] <skaet> [ACTION] victorp, look at adding hardware cert reports with architectures as one of the pieces of info tracked for this
[10:56:38] <victorp> skaet - next SRU?
[10:56:40] <ubottu> Launchpad bug 554172 in linux (Ubuntu) "system services using "console output" not starting at boot" [High,Confirmed] https://launchpad.net/bugs/554172
[10:57:07] <cjwatson> skaet: for the logs, could that upstart action be relative to bug 642555, please
[10:57:08] <ubottu> Launchpad bug 642555 in Ubuntu Lucid "Services not starting on boot in 10.04.1 LTS" [Medium,Confirmed] https://launchpad.net/bugs/642555
[10:57:16] <skaet> cjwatson, ack
[10:57:40] <sconklin> victorp: we have a security update in the works, which looks like it will cause us to skip a cycle
[10:58:23] <skaet> victorp, sconklin - ok, lets deal with this offline
[10:58:30] <sconklin> ack
[10:58:34] <sconklin> ..
[10:58:39] <victorp> ack - just need a date
[10:58:40] <victorp> :)
[10:59:03] <victorp> skaet - do we have an action for that?
[10:59:05] <skaet> [ACTION] victorp, skaet, bjf to set date for next one.
[10:59:15] * skaet needs to work on typing speed. ;)
[10:59:16] <sconklin> I'm away for the rest of this week - so bjf and skaet can figure it out
[10:59:26] <cjwatson> pitti: published
[10:59:42] <skaet> thanks everyone. will see if we can crisp up a bit for the next meeting in 2 weeks time.
[10:59:52] <victorp> thanks!
[10:59:55] <sconklin> thanks everyone!
[10:59:55] <skaet> minutes will be posted with agenda. :)
[11:00:00] <sconklin> thanks skaet
[11:00:04] <skaet> #endmeeting
Meeting ended.