Ubuntu Wiki

Log

UTC

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