Started logging meeting in #ubuntu-meeting<br />
[10:00:29] &lt;skaet&gt; Agenda can be found:<br />
[10:00:29] &lt;skaet&gt; [LINK]https://wiki.ubuntu.com/ReleaseTeam/Meeting/StableReleaseAgenda<br />
<a name='0'></a>
[10:00:40] &lt;skaet&gt; Reminder, please follow the convention  of using ".." on a separate line when you've finished typing.    Also, If someone wants to comment on the last point, please "o/", so we know to wait.<br />
[10:00:49] &lt;skaet&gt; Focus for this week is 10.04.2.<br />
[10:01:02] &lt;skaet&gt; [TOPIC] 10.04.2<br />
<a name='1'></a>
[10:01:52] &lt;skaet&gt; pitti,  2 milestoned bugs left - any update on them?<br />
[10:02:08] &lt;pitti&gt; skaet: I just moved the desktopcouch one which newly appeared on the 10.04.2 list to .3<br />
[10:02:25] &lt;skaet&gt; pitti,  thanks.<br />
[10:02:26] &lt;pitti&gt; a year after release it can't be that urgent to re-do all the cert and other validation<br />
[10:02:30] &lt;pitti&gt; what's the other one?<br />
[10:02:47] &lt;skaet&gt; foundations one that's been on the list a while.<br />
[10:02:52] &lt;skaet&gt; see on agenda.<br />
[10:03:12] &lt;pitti&gt; https://launchpad.net/ubuntu/+milestone/ubuntu-10.04.2 has quite a bit more, so it's a bit hard to see<br />
[10:03:22] &lt;skaet&gt; 635273:Building debs with SWIG libraries do not work<br />
[10:03:34] * skaet was just focusing on the high/critical <br />
[10:03:52] &lt;pitti&gt; this doesn't look like a deal-breaker for .2 at all<br />
[10:03:57] &lt;pitti&gt; I think we should just move it<br />
[10:04:19] &lt;skaet&gt; fair enough,  will confirm with cjwatson, but lets assume that's the case.<br />
[10:04:36] &lt;skaet&gt; what is the update on the language packs?   which ones landed?<br />
[10:04:40] &lt;pitti&gt; FTR, I'm still wrestling with langpacks, I have build take #4 running right now<br />
[10:04:59] &lt;pitti&gt; skaet: we'll land all of them in -proposed, and then quick-verify the ones that are shipped on the images<br />
[10:05:18] &lt;pitti&gt; on desktops, anyway (not DVDs, as they probably ship all of them)<br />
[10:05:37] &lt;pitti&gt; I hope I can get them uploaded to -proposed within 2 hours now<br />
[10:05:49] &lt;pitti&gt; I'll coordinate testing handover with dpm<br />
[10:06:06] &lt;pitti&gt; but if anything should go wrong, we just use what we have now<br />
[10:06:20] &lt;skaet&gt; pitti,  sounds good.<br />
[10:06:52] &lt;skaet&gt; ..?<br />
[10:08:14] * skaet wondering if pitti has anything else to add or is done, before moving on?<br />
[10:08:20] &lt;pitti&gt; ..<br />
[10:08:22] &lt;pitti&gt; sorry<br />
[10:08:25] &lt;skaet&gt; :)<br />
[10:08:32] &lt;skaet&gt; np<br />
[10:08:46] &lt;skaet&gt; ara,  how are we looking on HW cert?<br />
[10:08:56] &lt;ara&gt; * Almost all the servers and desktops are already covered. No regressions found so far. \o/<br />
[10:08:56] &lt;ara&gt; * This week the scope is testing laptops and netbooks and finishing the remaining desktops and servers.<br />
[10:08:56] &lt;ara&gt; We are on track to finish on time before Thursday.<br />
[10:09:02] &lt;ara&gt; ..<br />
[10:09:13] &lt;skaet&gt; ara,  thanks!  very good news.<br />
[10:09:24] &lt;skaet&gt; any questions for ara?<br />
[10:10:15] &lt;marjo&gt; ara: are there specific things you're depending on, or are all your dependencies ok?<br />
[10:10:34] &lt;ara&gt; marjo, everything is OK<br />
[10:10:36] &lt;marjo&gt; ara: in other words, there are no blockers for hw cert, right?<br />
[10:10:40] &lt;ara&gt; no :)<br />
[10:10:42] &lt;marjo&gt; ara: great to hear<br />
[10:11:00] &lt;skaet&gt; marjo, how are things looking from your side?<br />
[10:11:26] &lt;marjo&gt; skaet: this week we're doing the kernel/security testing<br />
[10:12:01] &lt;marjo&gt; and for 10.04.2, jibel has  started syncing images and will do upgrade testing this week.<br />
[10:12:03] &lt;marjo&gt; ..<br />
[10:12:45] &lt;skaet&gt; marjo,  sounds good.   encourage jibel to flag early if any issues show up with the upgrade testing ;)<br />
[10:12:50] &lt;marjo&gt; skaet: is there time today to discuss "tweaks to SRU kernel process"?<br />
[10:13:06] &lt;skaet&gt; marjo,  after 10.04.2 - we'll go on to SRU<br />
[10:13:09] &lt;jibel&gt; skaet, I will :-)<br />
[10:13:16] &lt;skaet&gt; thanks jibel<br />
[10:13:16] &lt;marjo&gt; skaet: thx much!<br />
[10:13:31] &lt;skaet&gt; pitti,  final images will be cut on Friday or Monday?<br />
[10:13:52] &lt;pitti&gt; can we do the final validation if we do them on Monday?<br />
[10:14:00] &lt;pitti&gt; would give us a tad more time for the langpacks<br />
[10:14:06] &lt;pitti&gt; but if Friday would be better, that works, too<br />
[10:14:41] &lt;skaet&gt; pitti,  suspect ara and jibel would prefer friday if at all possible,  so less of a scramble next week.<br />
[10:15:01] &lt;skaet&gt; ara, jibel - ?<br />
[10:15:33] &lt;ara&gt; skaet, I don't have a preference<br />
[10:15:38] &lt;jibel&gt; skaet, I'm fine with both<br />
[10:15:41] &lt;marjo&gt; pitti: what happens if you don't get the "tad more time for the langpacks" what's the downside risk?<br />
[10:16:21] &lt;pitti&gt; marjo: no risk involved; the less time we have, the fewer langpacks will make it to -updates, but no other harm done<br />
[10:16:39] &lt;skaet&gt; ok<br />
[10:16:44] &lt;pitti&gt; we don't depend on these, they would just be a "nice to have"<br />
[10:16:52] &lt;marjo&gt; pitti: understood; i like plans w/ "no risk involved" :)<br />
[10:17:18] &lt;marjo&gt; skaet: i would say let's go for Friday final image, ok?<br />
[10:17:28] &lt;pitti&gt; ack<br />
[10:17:28] &lt;marjo&gt; to avoid the scrambling<br />
[10:17:43] &lt;marjo&gt; pitti: thx much!<br />
[10:17:47] &lt;skaet&gt; pitti,  if langpaks are looking reasonable, cut the images on Friday and broadcast widely then.  If langpaks are problematic we can discuss.<br />
[10:18:04] &lt;pitti&gt; bah, they just failed again; firefox translations are broken<br />
[10:18:05] &lt;skaet&gt; we'll use u-release for discussions.<br />
[10:18:38] &lt;marjo&gt; pitti: will the initial langpacks include the ones used for the recent Qin image?<br />
[10:19:29] &lt;pitti&gt; Qin?<br />
[10:20:05] &lt;skaet&gt; Qin - chinese image<br />
[10:20:16] &lt;skaet&gt; marjo, wasn't that a maverick one?<br />
[10:20:33] &lt;marjo&gt; skaet: oh sorry<br />
[10:20:33] &lt;pitti&gt; I think so<br />
[10:20:39] &lt;skaet&gt; np<br />
[10:20:48] &lt;skaet&gt; any other questions about 10.04.2?<br />
[10:20:51] &lt;pitti&gt; marjo: but it only takes what launchpad translations has, no other sources<br />
[10:21:02] &lt;marjo&gt; pitti: then we're ok<br />
[10:21:02] &lt;pitti&gt; so if the chinese edition strings are on launchpad, it will be taken from langpack-o-matic<br />
[10:21:13] * skaet keeps fingers crossed its only langpacks that are problematic for 10.04.2<br />
[10:21:28] &lt;skaet&gt; ok,  moving on..<br />
[10:21:39] &lt;skaet&gt; [TOPIC] SRU updates<br />
<a name='2'></a>
[10:22:05] &lt;skaet&gt; sconklin - what's happening with the kernels?<br />
[10:22:18] &lt;sconklin&gt; |<br />
[10:22:18] &lt;sconklin&gt; | Latest Lucid -proposed is 2.6.32-29.57<br />
[10:22:18] &lt;sconklin&gt; | Call for verification went out on Feb 4th<br />
[10:22:18] &lt;sconklin&gt; |<br />
[10:22:18] &lt;sconklin&gt; | Latest Maverick -proposed is 2.6.35-26.46<br />
[10:22:19] &lt;sconklin&gt; | Call for verification went out Feb 1st<br />
[10:22:19] &lt;sconklin&gt; |<br />
[10:22:20] &lt;sconklin&gt; | These were both copied out to -proposed last week.<br />
[10:22:20] &lt;sconklin&gt; |<br />
[10:22:21] &lt;sconklin&gt; | The status page with tracking bugs is here.<br />
[10:22:21] &lt;sconklin&gt; | Our tools will need changes to accomodate<br />
[10:22:22] &lt;sconklin&gt; | the ARM based kernels, so ignore all the information<br />
[10:22:22] &lt;sconklin&gt; | on that page for ARM kernels.<br />
[10:22:23] &lt;sconklin&gt; |<br />
[10:23:15] &lt;sconklin&gt; I got throttled, hold on<br />
[10:23:32] &lt;sconklin&gt; |<br />
[10:23:32] &lt;sconklin&gt; | https://kernel-tools.canonical.com/srus.html<br />
[10:23:32] &lt;sconklin&gt; |<br />
[10:23:33] &lt;sconklin&gt; ..<br />
[10:23:46] &lt;skaet&gt; what are the tracking bug numbers for maverick, lucid?<br />
[10:23:56] &lt;sconklin&gt; they are in the page I just linked<br />
[10:24:05] &lt;skaet&gt; thanks<br />
[10:24:31] &lt;skaet&gt; any questions for sconklin?<br />
[10:24:54] &lt;ara&gt; o/<br />
[10:25:08] &lt;skaet&gt; go ara<br />
[10:25:22] &lt;ara&gt; As we said, we were no going to be able to test SRUs this week. What is going to happen, then?<br />
[10:25:37] &lt;ara&gt; a new kernel is going to be uploaded next week?<br />
[10:25:54] &lt;sconklin&gt; Whatever is done will just wait in the queue until you are able to test<br />
[10:26:28] &lt;ara&gt; OK<br />
[10:26:30] &lt;marjo&gt; sconklin: does that mean QA team should hold off also?<br />
[10:26:32] &lt;sconklin&gt; We may upload new kernels to the PPA, but they will not be copied into -proposed until the ones in -proposed are published to updates<br />
[10:26:58] &lt;marjo&gt; sconklin: or keep going w/ regression testing starting today?<br />
[10:27:58] &lt;sconklin&gt; I thought that you were unable to do regression testing. Whether you can test or not and when cert can test will determine what we do next.<br />
[10:28:31] &lt;marjo&gt; sconklin: we can do "regression testing" this week, since alpha2 is done<br />
[10:28:34] &lt;sconklin&gt; If there will be no testing in the next week, we can just roll a new version to -proposed, and you can test that after a week in verification.<br />
[10:29:25] &lt;sconklin&gt; if Cert is blocked for another week, then it probably makes sense for us to publish new -proposed, and take all the existing verifications as done<br />
[10:29:31] &lt;marjo&gt; jibel: any suggestions?<br />
[10:29:35] &lt;skaet&gt; marjo,  thinking in dallas, was that this was opportunity to catch up on hardy and karmic.<br />
[10:29:59] &lt;sconklin&gt; skaet: catch up meaning what?<br />
[10:30:13] &lt;skaet&gt; sconklin,  run the regression testing<br />
[10:30:45] &lt;sconklin&gt; extra regression testing will never hurt, even if the tested versions are superseded in -proposed and not ultimately released<br />
[10:31:07] &lt;skaet&gt; sconklin,  was refering to hardy & karmic<br />
[10:31:26] &lt;skaet&gt; ?<br />
[10:31:34] &lt;sconklin&gt; that statement applied to every series<br />
[10:31:37] &lt;skaet&gt; heh<br />
[10:31:39] &lt;skaet&gt; :)<br />
[10:31:39] &lt;sconklin&gt; applies<br />
[10:32:15] &lt;sconklin&gt; but - in particular, we are concerned about server and virt testing for hardy in this and the next release<br />
[10:32:48] &lt;skaet&gt; marjo, jibel - ok to look at hardy, karmic this week?   then back into the regular pattern after 10.04.2 comes out.<br />
[10:32:54] &lt;sconklin&gt; (probably) for the next because there are some more rather invasive patches in the queue but they haven't been finalized<br />
[10:33:10] &lt;sconklin&gt; should good to me<br />
[10:33:15] &lt;marjo&gt;  skaet: ok, will do<br />
[10:33:16] * pitti waves, need to leave<br />
[10:33:18] &lt;sconklin&gt; er . . . sounds good<br />
[10:33:29] * skaet thanks pitti<br />
[10:33:57] &lt;skaet&gt; sconklin,  er... ?<br />
[10:34:13] &lt;skaet&gt; have I misunderstood/overlooked something?<br />
[10:34:23] &lt;sconklin&gt; sounds good to me to test Hardy and Karmic<br />
[10:34:27] &lt;sconklin&gt; ..<br />
[10:35:30] &lt;skaet&gt; ara - any updates/questions?<br />
[10:35:46] &lt;ara&gt; skaet, not from me<br />
[10:35:46] &lt;jibel&gt; so, on the QA side the plan is to do regression testing on Karmic and Hardy this week, then what's in -proposed for maverick and lucid after 10.04.2 is out ?<br />
[10:36:10] &lt;skaet&gt; jibel,  yup,  that's my understanding<br />
[10:36:19] &lt;marjo&gt; jibel: yup, that's my understanding<br />
[10:36:20] &lt;jibel&gt; okay. thanks<br />
[10:36:30] &lt;ara&gt; the certification team is not planning on testing until the week 19, as marked in:<br />
[10:36:31] &lt;ara&gt; https://wiki.ubuntu.com/NattyReleaseInterlock<br />
[10:36:45] &lt;skaet&gt; ara,  yup.  :)<br />
[10:36:46] &lt;sconklin&gt; with the understanding that we may roll out a new -propsed for lucid and maverick before testing gets to it<br />
[10:37:03] &lt;skaet&gt; sconklin,  ack.<br />
[10:37:10] &lt;marjo&gt; sconklin: ack<br />
[10:37:35] * skaet is doing a good snap set with marjo.  ;)<br />
[10:37:48] &lt;skaet&gt; any other questions about SRU updates?<br />
[10:38:02] &lt;skaet&gt; marjo did you want to talk about tweaks?<br />
[10:38:08] &lt;marjo&gt; skaet: thx<br />
[10:38:12] &lt;marjo&gt; hi folks<br />
[10:38:37] &lt;marjo&gt; i have a few simple tweaks and suggestions for the Kernel SRU process<br />
[10:39:23] &lt;marjo&gt; 1. I suggest that this be an agenda item for the SRU & LTS meeting, and make sure HW Cert team raise issues early. I've already asked Kate to include it.<br />
[10:39:50] &lt;marjo&gt; 2. Ensure all critical and high importance bugs are verified in a timely manner. If not, Jean-Baptiste or his backup will perform the testing.<br />
[10:40:03] &lt;marjo&gt; 3. Jean-Baptiste will specifically ask at the meeting if there are specific bugs that need verification that aren't being done by the bug reporter. If necessary, a QA team member will do the verification. If not able (e.g. lack of specific HW), will do more calls for testing and nag the bug reporter again.<br />
[10:40:14] &lt;marjo&gt; 4. Set up separate SRU verification program, for big packages like eglibc, python, X. As you know, we've done that before for mesa.<br />
[10:40:16] &lt;marjo&gt; ..<br />
[10:40:52] &lt;marjo&gt; too bad pitti's not here...<br />
[10:41:02] &lt;sconklin&gt; for 3, who will do the tracking and asking?<br />
[10:41:50] &lt;marjo&gt; sconklin: by default, jibel, but we don't want to duplicate efforts already in place by pitti & sconklin<br />
[10:42:07] &lt;skaet&gt; marjo,  yeah,  we need to take this suggestion up with with pitti off line as well.<br />
[10:42:22] &lt;sconklin&gt; marjo, so are you proposing that someone from QA begin to track all the bugs requiring verification?<br />
[10:42:28] &lt;marjo&gt; sconklin: i'm trying to avoid the last minute scrambling to do fix verification when bug reporters don't do them<br />
[10:43:06] &lt;pitti&gt; still catching up on backscroll, but only 1/4 brain here<br />
[10:43:07] &lt;marjo&gt; sconklin: no, we just want to get heads up on those that are not getting verified in a timely manner<br />
[10:43:08] &lt;sconklin&gt; Has there been a problem with this? We have had almost 100% of verifications done quickly for the last few cycles<br />
[10:43:31] &lt;sconklin&gt; And has that impacted QA or cert?<br />
[10:43:31] &lt;pitti&gt; also, the kernel is really quite special here<br />
[10:43:43] &lt;pitti&gt; we just need a large amount of testing there because it changes so much<br />
[10:43:53] &lt;bjf&gt; marjo, are you trying to solve a real problem today or anticipating an issue ?<br />
[10:43:59] &lt;pitti&gt; we don't allow these kind of changes in any other package (like in X.org)<br />
[10:44:39] &lt;marjo&gt; bjf: i'm trying to head off the cases where bug reporter doesn't do verification, so someone (QA team) has to try<br />
[10:44:58] &lt;skaet&gt; sconklin, marjo - tags of verification needed can be surveyed to figure out which are outstanding,  and then look at high/critical.<br />
[10:44:59] &lt;marjo&gt; and we want to know ASAP<br />
[10:45:11] &lt;sconklin&gt; marjo: How often has this happened? I wasn't aware that this was happening<br />
[10:45:19] &lt;marjo&gt; skaet: yes, that's one way to implement this<br />
[10:45:22] &lt;bjf&gt; marjo, we have a clear policy on that, if it's not verified by the reporter, we revert the patch<br />
[10:45:59] &lt;skaet&gt; sconklin,  bjf - outside the kernel,  there are some good fixes getting no love, since the reporter is the one that fixed it.<br />
[10:46:12] &lt;marjo&gt; bjf: ok, so maybe these don't apply to kernel, because it's more well behaved<br />
[10:46:26] &lt;sconklin&gt; oh, sorry. I'm in my kernel bubble<br />
[10:46:37] &lt;marjo&gt; sconklin: yes, you are :)<br />
[10:46:56] &lt;skaet&gt; [LINK] http://people.canonical.com/~ubuntu-archive/pending-sru.html<br />
<a name='3'></a>
[10:47:13] &lt;sconklin&gt; well, you said that these were kernel SRU tweaks, . . .<br />
[10:47:25] &lt;marjo&gt; sconklin: yes, i did ..<br />
[10:47:52] &lt;sconklin&gt; Have you been having to do verification for any kernel bugs?<br />
[10:47:59] &lt;marjo&gt; sconklin: would you say that this is NOT a problem for the kernel case<br />
[10:48:00] &lt;marjo&gt; ?<br />
[10:49:09] &lt;marjo&gt; sconklin: in general, we (QA team) try to verify fixes if the bug reporter doesn't<br />
[10:49:10] &lt;sconklin&gt; it's not a problem because if people don't test their changed we revert them. I know that some people have had to scramble for testing because they lacked hardware, but I didn't know that it was falling on your team. If it is, we'll look at it<br />
[10:49:25] &lt;marjo&gt; but only if we have the HW, resources, etc.<br />
[10:49:30] &lt;marjo&gt; we try to help...<br />
[10:49:52] &lt;marjo&gt; sconklin: thx much<br />
[10:50:01] &lt;skaet&gt; marjo, sconlin,  thanks.<br />
[10:50:03] &lt;sconklin&gt; marjo: ok, that sounds great - and the best way to determine what needs verification is just to look at our sru status page and see what's not verified<br />
[10:50:07] &lt;marjo&gt; skaet: so i think that's it from me<br />
[10:50:10] &lt;victorp&gt; marjo for #1 could you give an example when hw cert have not raised an issue early?<br />
[10:50:40] &lt;sconklin&gt; If you can verify fixes and save us the pain of reverting and get good fixes out, I'm all for that<br />
[10:51:24] &lt;marjo&gt; victorp: remember ara had to raise the issue re: eglibc? i think you and i agree this should have been caught earlier<br />
[10:51:38] &lt;marjo&gt; victorp: that's why i'm making these suggestions<br />
[10:51:51] &lt;marjo&gt; so, hw cert doesn't have to scramble<br />
[10:52:13] &lt;marjo&gt; sconklin: ack<br />
[10:52:17] &lt;victorp&gt; yes, but couldnt possibly find it earlier because we are not involve in it<br />
[10:52:28] &lt;marjo&gt; victorp: we know<br />
[10:52:38] &lt;victorp&gt; basically QA has to find it earliear so it is not up to hw cert to find it<br />
[10:52:47] &lt;marjo&gt; victorp: we know<br />
[10:53:05] &lt;marjo&gt; victorp: we're trying to help you (HW cert)<br />
[10:53:19] &lt;victorp&gt; marjo, great<br />
[10:53:25] &lt;marjo&gt; victorp: thx!<br />
[10:53:35] &lt;victorp&gt; in that case you may rephrase the problem statement<br />
[10:53:37] &lt;marjo&gt; skaet: thx, that's it from me<br />
[10:53:45] &lt;skaet&gt; okie,  thanks.<br />
[10:53:48] &lt;victorp&gt; and it will help every one if we get it right not just he cert<br />
[10:53:52] &lt;victorp&gt; hw cert<br />
[10:53:59] &lt;marjo&gt; victorp: ack<br />
[10:54:09] &lt;skaet&gt; before meeting ends... any input from security,  OEM,  support teams?   any escalations?<br />
[10:54:52] * skaet looks around?<br />
[10:55:08] &lt;skaet&gt; any other questions?<br />
[10:55:16] &lt;skaet&gt; going once<br />
[10:55:19] &lt;skaet&gt; going twice<br />
[10:55:25] &lt;skaet&gt; #endmeeting<br />
Meeting ended.<br />