== Log == UTC {{{ [17:00] #startmeeting [17:00] Meeting started at 11:00. The chair is heno. [17:00] Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] [17:00] Congratulations everyone on a successful release! [17:00] hey there [17:01] The testing was quite hectic at the end but it seems we got there :) [17:01] yeah, fun last iso testing night :) [17:02] Agenda as usual here: https://wiki.ubuntu.com/QATeam/Meetings [17:02] * stgraber grabs some food (lunch time here) [17:02] [TOPIC] Identifying and dealing with regressions in a -proposed package. While most information should end up in the SRU bug report should new bug reports be tagged regression-proposed? Should these start being tracked? [17:02] New Topic: Identifying and dealing with regressions in a -proposed package. While most information should end up in the SRU bug report should new bug reports be tagged regression-proposed? Should these start being tracked? [17:03] There was some discussion about this in #ubuntu-bugs the other day and it was suggested that we use regression-proposed to identify these. [17:04] I think it would be reasonable to track these with a tag. [17:04] +1 [17:04] yes, could those be added to the sru tracker page somewhere? [17:04] Usually a regression found in an SRU candidate should block it's move to updates [17:04] btw does anyone still have issues with sbeattie sru page? [17:05] sbeattie: Comments about epic failures should happen in the SRU bug though, correct? [17:05] at which point it's not a regression [17:05] it's way slow here :-( [17:05] But it needs to be made explicit that regression should also be mentioned in the original SRU bug as well. [17:05] pedro_: it's sometimes slow to render and I'm not sure why. [17:05] bdmurray: correct [17:05] what would be a typical use case for this? [17:06] Hi [17:06] a proposed update that we object to on the grounds of a discovered regression? is that what we are tagging? [17:07] heno: yes [17:07] The situation that came up is that someone submitted a bug about a -proposed package for unknown reasons... [17:07] Is the purpose to track historically how many SRUs were put forward with regressions in them or to have a list of currently blocked SRUs? [17:08] So tagging these bugs would allow the SRU verification team to find these regression-proposed bugs that the bugsquad has identified. [17:09] bdmurray: oic, this would be a tab for new bugs filed against -proposed packages, not the SRU bug itself [17:09] that makes sense [17:10] Ideally, this shouldn't happen as the person running the -proposed should know which bug to comment on but you never know. [17:10] on a similar note, the kernel team has now decided to open 1 SRU bug report for each 2.6.27.y upstream stable kernel patch set. any regressions will warrant a new bug being opened for that regression. [17:11] https://lists.ubuntu.com/archives/kernel-team/2008-November/003406.html [17:11] ogasawara: that sounds reasonable [17:12] ok, looks like we are agreed. Let's add regression-proposed to the regression tracking description page [17:12] https://wiki.ubuntu.com/QATeam/RegressionTracking [17:12] and update the EnableProposed page with the tag and commenting on the SRU bug [17:13] sbeattie: will you do that? [17:13] yes, can you #action it? [17:14] [ACTION] sbeattie to update RegressionTracking and EnableProposed wiki pages with regression-proposed info [17:14] ACTION received: sbeattie to update RegressionTracking and EnableProposed wiki pages with regression-proposed info [17:15] [TOPIC] Hardy SRU Verifications still a lot to do and a really old ones (~100 days) [17:15] New Topic: Hardy SRU Verifications still a lot to do and a really old ones (~100 days) [17:15] We are processing Intrepid SRUs now, but there are still some Hardy SRUs outstanding [17:15] We got behind there due to focusing on intrepid, but I expect to start making progress on them again. [17:15] I have a machine with a partition with Hardy, I could give some help clearing that up [17:15] ara: that would be great! [17:16] ara: that would be great! [17:16] sbeattie, heno: are you the same person? [17:16] dude you're so connected :-P [17:16] I'm giving an open week session tomorrow on SRU verifications, I'll also solicit for assistance there. [17:16] anyone else who can lend a hand, that would be appreciated too! [17:16] ara: I think you just insulted heno. :-) [17:17] if someone could take bug 204133, that'd be really neat, that's the oldest bug there, 118 days old [17:17] sbeattie: no, no. no worries :) [17:17] Launchpad bug 204133 in wubi/8.04 "wubi install unusable - Buffer I/O error on device loop0" [High,In progress] https://launchpad.net/bugs/204133 [17:18] it does look like a pure copy and paste though :) [17:19] let's ask davmor to look at that when he returns [17:19] our resident wubi test expert [17:20] I don't see a test case right away [17:21] It might make more sense to follow up with agostino and see what the status is / what needs to happen. [17:22] I'll do that since I reported the original bug. ;-) [17:22] I suspect it needs to be release before the 8.04.2 respin [17:22] bdmurray: ok, thanks [17:23] openldap is old too [17:23] heno: good point, I'll milestone it. [17:23] and python-apt [17:25] sbeattie, ara: We've talked about runing an SRU testing day. Should we schedule that? [17:26] (do others agree it's good idea?) [17:26] heno: historically testing days are Mondays [17:27] sbeattie: you are giving a class at openweek right? [17:27] (with a history of 3) [17:27] :) [17:27] bdmurray: yes, tomorrow [17:27] perhaps capitalizing on that with a SRU day afterwards would be good [17:27] this might be a good time, as we don't have ISOs to test [17:27] bdmurray: good point [17:29] ara: could you coordinate with sbeattie on a basic plan for the day and announce it? [17:29] ara: how much prep work did you do for the testing days? [17:29] make sure to add it to https://wiki.ubuntu.com/UbuntuBugDay/Planning aswell ;-) [17:29] sbeattie: some doc preparation and wiki update [17:30] sbeattie: blogging and some spam on the lists [17:30] heno: yes, sure [17:30] [ACTION] ara and sbeattie to plan an SRU testing day for Monday [17:30] ACTION received: ara and sbeattie to plan an SRU testing day for Monday [17:30] cool! [17:31] heno: next Monday I am on holidays, though :( [17:31] heno: but I can help with the prep work [17:32] heno: and the post work [17:32] ara: ok thanks. We can run it in your absence :) [17:32] sbeattie and I work as one ;) [17:33] [TOPIC] Application test cases [17:33] New Topic: Application test cases [17:33] There were some posts on planet about this yesterday and we've seen some new test case contributions [17:33] https://wiki.ubuntu.com/Testing/Applications [17:34] It's good to see new contributions here though we need to merge it with the content here https://testcases.qa.ubuntu.com/Ubuntu/Applications [17:35] mpt mentionned that having a second website for test cases might cause duplication or desynchronization between the two [17:35] The migration to the test case wiki was left hanging a bit during release, but we should pick it up again [17:36] How are we going to handle redirection once we move to the new wiki? [17:36] cr3: we are seeing some of that confusion now, but I think we should migrate all the cases over to the testcases wiki [17:37] schwuk: redirect of just old test case URLs or WRT to the iso tracker? [17:37] heno: the old URLS [17:37] heno: is there a particular reason to have a separate wiki for test cases? [17:38] schwuk: I would change the pages to "there is a new test case wiki, please visit http:..." [17:38] schwuk: redirecting will refrain people to know that there is a new one [17:38] sorry guys, i didnt know that wiki existed :( [17:38] schwuk: and they could keep adding new test cases to the old one [17:39] schwuk: adding a note about the new wiki on https://wiki.ubuntu.com/Testing/Cases should do - I don't think we need to redirect all the pages [17:39] pages in wikis move around and are deleted all the time; people are used to that [17:40] I'm not used to that, but that's just me :) [17:40] LaserJock: it is so we can give it more structure, add custom macros, lock down pages that we then parse to generate scripts automatically, etc [17:41] there are good reasons, we're just not there yet [17:41] just wondered, as Ubuntu has a bit of a wiki-mania problem ;-) [17:41] here here! [17:42] ara: will you pick up the page migration effort again? please coordinate with davmor and the new contributors [17:42] heno: yes. I have already talked with davmor about it. We are working on it [17:42] ara: excellent, thanks [17:43] (no action item required then) [17:43] [TOPIC] Meting times (post DST change) [17:43] New Topic: Meting times (post DST change) [17:43] yeah, basically I'd like to avoid QA meeting on my lunch time :) [17:44] "no, no please" would sound too pathetic? [17:44] an hour before or an hour after would be great, or any other time (we can discuss it) === maco_ is now known as maco [17:45] "no, no please" not before [17:45] :) [17:45] an hour before is 8.00am in Portland [17:45] bdmurray: c'mon 8am meetings are fun. [17:45] ara: your 'no, no' was about an hour after? [17:46] heno: yes. i was soooooo happy about DST! [17:46] I would also prefer not to shift it later because we have another meeting after this too [17:46] ara: yeah, so was I ... but I need a workaround for the next 6 months :) [17:46] i would prefer no not shift ;-) [17:47] stgraber: can you change your lunch time once a week? [17:47] stgraber: lunch time was an issue for me previously to the DST :-P [17:47] heno: not really, we usually go out for lunch and I can't hardly ask everyone in the company to change the lunch time :( [17:48] pack a lunch one day? [17:48] well, I can probably read the log afterwards though and deal with the few items I have by mail [17:49] except the ISO testing and approving/declining members, I'm not that much involved in the QA team anyway [17:49] stgraber: also feel free to catch me or other team members on phone or skype at other times [17:50] ok [17:50] Seems there is a majority vote too keep the current meeting time (UTC) === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Edubuntu Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 10 Nov 18:00: LoCo Council | 11 Nov 16:00: Server Team | 18 Nov 11:00: Community Council | 18 Nov 16:00: Server Team | 21 Nov 20:00: Tunisian LoCo Team IRC [17:50] any other business? [17:51] ok, thanks everyone! [17:51] #endmeeting }}}