20071114

Log

UTC

16:01   MootBot Meeting started at 16:01. The chair is heno_.
16:01   MootBot Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
16:02   heno_   welcome all!
16:02   heno_   we have an agenda here https://wiki.ubuntu.com/QATeam
16:04   liw     I have nothing to add to the agenda
16:04   heno_   [TOPIC] Spec status
16:04   MootBot New Topic:  Spec status
16:04   heno_   is everyone who has specs comfortable with getting them written up and with the review process?
16:05   liw     I'm new to the review process, but I'll ask questions if and when I have any
16:05   ogasawara       is there a wiki describing the review process somewhere?
16:06   bdmurray        With regards to an informational spec is it necessary to write up the spec?  With the QA schedule it seems a bit redundant.
16:06   heno_   the review team is listed here https://edge.launchpad.net/~ubuntu-reviewers
16:06   liw     my DesktopAutomatedTests is basically written, I'm just going to review it myself before submitting it for review; SelfTestingDesktop is still to be written, but since it's a corollary of the other one, it should be pretty quick to do
16:06   heno_   you should ask one of them to review when you feel it's complete
16:07   heno_   I don't see a wiki page
16:07   ogasawara       heno_:  I assume we should submit for review by the end of the week?
16:07   heno_   this should have been covered by the UDS howto I guess
16:08   heno_   ogasawara: yes, that would be good, to allow for some ping-pong
16:09   heno_   stgraber: did you make it to the meeting? you have several specs needing review also
16:09   heno_   stgraber: (let me know if we should have a post-UDS conversation about this)
16:10   heno_   ok, that seems clear; moving on
16:11   heno_   [ACTION] everyone should complete the spec formulations and submit them for review by the end of this week
16:11   MootBot ACTION received:  everyone should complete the spec formulations and submit them for review by the end of this week
16:11   heno_   [TOPIC] Feedback on Hardy QA schedule
16:11   MootBot New Topic:  Feedback on Hardy QA schedule
16:12   heno_   Brian asked for some feedback on the QA schedule on the list
16:12   ogasawara       the schedule looked fine to me
16:12   heno_   me too
16:13   pedro_  yep good for me too
16:13   heno_   bdmurray: will you pass it on the the release team next?
16:13   liw     good for me too, even if it doesn't have a date for when I'm allowed to report fourteen thousand bugs automatically
16:13   bdmurray        heno_: sure - they don't have a mailing list right?
16:14   heno_   I don't think they do, no
16:14   bdmurray        pedro_: looking at it again I seem to have missed forwarding bugs upstream that would be until about week 8 right?
16:14   heno_   liw: I guess that would be when we can trust it to DTRT
16:15   liw     heno, sure, I was trying to be funny anyway
16:15   heno_   bdmurray: you mean Gutsy bugs? I assume we forward bugs continuously in the dev release
16:16   pedro_  i don't think so
16:16   bdmurray        heno_: We discussed forwarding being more helpful until syncs stop
16:17   bdmurray        s/more helpful/useful/
16:17   bdmurray        after which we need to patch our version of the package
16:18   heno_   bdmurray: are they considered less useful closer to release because upstream are less likely to fix or because of ubuntu-specific changes
16:18   heno_   gnome is a special case that gets synced quite late I guess
16:19   heno_   liw: sure. are there automated-test milestones that should go on a regular schedule though I wonder?
16:19   heno_   it might be difficult to tell in our first cycle of doing it
16:20   bdmurray        heno_: because after import freeze the packages become more divirgent so while upstream may have fixed the bug they may have also done a lot of other things that we can't sync after import freeze
16:20   liw     heno, I don't think so, for the first cycle
16:20   heno_   ok
16:21   heno_   bdmurray: ok. I guess at that point developers will upstream individual issues they feel they need help with
16:21   heno_   [AGREED] Everyone agreed that it was a nice schedule :)
16:21   MootBot AGREED received:  Everyone agreed that it was a nice schedule :)
16:22   heno_   [TOPIC] Gutsy bug triage, looking for SRU candidates
16:22   MootBot New Topic:  Gutsy bug triage, looking for SRU candidates
16:24   bdmurray        I've been doing a fair bit of SRU verification for candidates already identified
16:25   heno_   there is only about a week and a half left of this phase. is it coordinated with the release team WRT for how long we will roll out fixes?
16:26   stgraber        I'm here
16:26   heno_   roughly how many bugs have we identified so far that should get gutsy SRUs?
16:26   bdmurray        The schedule is an indication of our primary focus after this week and a half we will shift to looking more at Hardy
* heno_ waves to stgraber
16:27   bdmurray        ogasawara: do you have the gutsy verification needed query?
16:27   heno_   are there any gutsy bugs that stick out as esp. high-profile?
16:28   ogasawara       bdmurray: I'll check, just a sec
16:28   heno_   how many are new and how many are ones we didn't mange to fix before release?
16:28   bdmurray        I think I have verified the updates for most of the really high-profile ones
16:28   stgraber        yes, I have 4 specs to work on, I've already talked a bit with _nand about the Tokamak one, I'll try to work on that tomorrow morning (note the "try" as I have a lot of other things to do :))
16:29   stgraber        btw, davmor2 asked me to paste that during the meeting :
16:29   stgraber        14:16 < davmor2> 1/ would it be better to bug test before the end of the freeze? That way when the freeze is on everything should be stable?
16:29   stgraber        14:16 < davmor2> 2/ with the schedule there is iso-testing latter on but not at the beginning is that how it is meant to be?
16:29   heno_   stgraber: indeed. let me know if you need help with those
16:30   ogasawara       bdmurray: I don't
16:30   bdmurray        stgraber: The schedule just indicates where our primary focus lies, iso-testing can happen as early as Alpha 1
16:30   ogasawara       bdmurray: but it shouldn't be hard to do
* bdmurray waits for it
16:31   heno_   2> by 'ISO testing' here we mean intensive testing with redundant coverage involving the dev team and others
16:31   pedro_  shouldn't be something like https://bugs.launchpad.net/ubuntu/gutsy/+bugs?field.tag=verification-needed ?
16:32   heno_   whereas earlier we do more spot/sanity checks on ISOs
16:32   bdmurray        pedro_: sure enough
16:32   pedro_  there's also http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
16:32   ogasawara       eww, the link I've got in launchpad is long
16:33   bdmurray        I'm working on 17595 atm
16:34   heno_   nice page
16:34   bdmurray        one thing about the lp query is it doesn't show the repository
16:36   heno_   on davmor2's pt. 1, I'm not sure which freeze he is referring to. Things do change after the freeze too though and simple errors can get introduced that are not caught by regular use
16:37   heno_   such as the late change cause the Kubuntu installer to fail
16:37   heno_   which I think was typo-level coding error
16:38   heno_   ok, let's move the the next topic, which is related but needs some discussion
16:39   heno_   [TOPIC] Managing Gutsy and Dapper SRU nominees
16:39   MootBot New Topic:  Managing Gutsy and Dapper SRU nominees
16:39   heno_   please look at https://edge.launchpad.net/ubuntu/gutsy/+nominations
16:40   heno_   and https://edge.launchpad.net/ubuntu/dapper/+nominations
16:40   bdmurray        The nominations are where anybody decides to nominate a bug for a release right?
16:41   heno_   right
16:41   bdmurray        How or why should they be managed?
16:42   heno_   we need to look at that list regularly to identify good candidates and make sure those reports get triaged
16:42   heno_   so that they can be moved forward to qualify for the SRU process
16:43   heno_   some will be not important enough and the nominations should be rejected
16:43   heno_   do you folks have the LP powers to accept/decline those?
16:44   bdmurray        I think only ubuntu-drivers does
16:44   heno_   which explains why I can
16:45   bdmurray        I can too - for spec stuff at UDS I was added to that team
16:45   heno_   I think the core triage team at least should have those powers
16:45   pedro_  I can't :-(
16:46   bdmurray        One thing about this process that bothers me is anyone can nominate
16:46   heno_   ok, I'll ask for pedro_ and ogasawara to be granted the appropriate LP powers
16:46   ogasawara       thanks
16:46   bdmurray        looking at bug 109882 it is one person with the issue and they nominated the bug
16:46   pedro_  great
16:46   ubotu   Launchpad bug 109882 in fedora "Headphone automute not working" [Unknown,Fix released] https://launchpad.net/bugs/109882
16:46   heno_   bdmurray: true, that makes it noisy. but the lists are not extremely long
16:46   ogasawara       bdmurray: heh, was just looking at that too
16:47   bdmurray        ogasawara: does l-b-m have the right version of alsa?
16:47   ogasawara       bdmurray: I think the version of alsa they want might already be in lbm
16:47   bdmurray        jinx you owe me a beer
16:47   ogasawara       bdmurray: checking on it right now
16:47   heno_   the advantage is that it can help bring up important issues
16:48   heno_   provided we look at the list regularly and it doesn't get abused
16:49   heno_   bdmurray: many of those were nominated before the gutsy release, when it made more sense, as that wouldn't be an SRU
16:50   heno_   we should do a one-time run-through after each release to remove those that clearly don't qualify
16:50   heno_   bdmurray: can bughelper help us identify those?
16:50   bdmurray        heno_: I haven't looked at the nomination property of a bug before but will look into it
16:51   heno_   thanks
16:51   heno_   it doesn't look like the point at which it was nominated gets logged automatically
16:53   ogasawara       bdmurray: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy-lbm.git;a=commit;h=d33c164bb93d09f21fd331a726052b66e40c26ab
16:54   heno_   all: please look out for nominated bugs when looking at gutsy bugs these days and ask me or brian to reject obvious non-SRU candidates
16:54   heno_   I'll do a more explicit run-through of that list next week
16:55   pedro_  ook
16:55   bdmurray        ogasawara: do you want to follow up on the bug and I'll rjeect the nominations?
16:55   ogasawara       bdmurray: sure
16:56   bdmurray        well, that's wacky
16:56   bdmurray        then nominations show up on a per package basis
16:56   heno_   let's revisit the status of this list next week. there are currently 358 bugs on it
16:56   bdmurray        so declining it for gutsy did it for both packages
16:57   bdmurray        which wasn't what I expected
16:58   bdmurray        heno_: we are only concerned about nominations for packages in main right?
16:59   heno_   hm, good question. it would be good to clean the list generally
16:59   heno_   where is the MOTU policy on updates?
17:00   heno_   is it mainly backports?
17:00   bdmurray        I think they incorporated it into the main SRU policy
* Hobbsee looks in
17:01   heno_   yep, I see it now
17:01   Hobbsee heno_: pretty much the same as main, although a little less beaurocracy.  new features --> backports, bugfixes --> SRU
* bdmurray waves to Hobbsee
17:03   heno_   Hobbsee: ok. who from MOTU could we get to go through that list regularly? the MOTU council perhaps?
17:03   heno_   also, you shouldn't have to be a driver to accept/reject such nominations
17:04   heno_   I'm not sure they belong on that list in the first place
17:05   heno_   from the user's POV it makes sense to nominate packages equally though
17:06   heno_   I'll raise that question on the MOTU list and with various ubuntu drivers
17:07   heno_   [ACTION] mdz to evaluate list of Gutsy nominated bugs and raise questions on the MOTU and devel lists
17:07   MootBot ACTION received:  mdz to evaluate list of Gutsy nominated bugs and raise questions on the MOTU and devel lists
17:08   bdmurray        heh - 154 nominated bugs are "New"
17:08   heno_   indeed, which is why the QA team has a role to play in an initial screening of the list
17:08   Hobbsee oh, thisthing doesnt flash when done backwards.
17:08   Hobbsee bdmurray: hiya!
17:09   Hobbsee heno_: erm, you only have to be in -release to accept or deny the nominations
17:09   Hobbsee heno_: sec, let me see the list.  i wasnt following :)
17:09   heno_   some of them will need improving (triaging) soonish, while others are less important and should be pushed to hardy
17:10   bdmurray        Hobbsee: was the universe report helpful at all?
17:10   Hobbsee bdmurray: it wasnt what i was looking for, but it looks somewhat useful.
17:11   bdmurray        Hobbsee: okay well let me know if you need anything else
17:11   Hobbsee heno_: ubuntu-universe-sponsors does it usually.
17:11   Hobbsee bdmurray: will do.  but not at 4am :)
17:12   heno_   Hobbsee: ok, thanks
17:12   Hobbsee heno_: but there may be another team starting up to do it.  unsure.  will find out in the next week or so
17:12   heno_   [TOPIC] QA team weekly meeting times
17:12   MootBot New Topic:  QA team weekly meeting times
17:12   heno_   always a controversial one :)
17:13   heno_   bdmurray: what time is 16.00 in OR?
17:13   Hobbsee just do away with the meetings.  problem solved :P
17:13   heno_   we've tried that before :p
17:13   liw     I think these meetings are useful, although they take a bit longer than I'd like
17:14   heno_   ut that was before we had a team really ;)
17:14   liw     it's 09:14 in Oregon (US west coast) right now
17:14   bdmurray        right 1600 was 0800
17:14   heno_   ok, so earlier would not be so good
17:15   bdmurray        yes, that would be bad
17:15   stgraber        wouldn't be good for me neither (would be at school)
17:15   heno_   liw: I agree, we should try to limit them to 1hr.
17:15   liw     I'm not throughly happy about 1600 UTC, but I can live with this (especially, as noted, if we can make them at most 1 hour :)
17:16   heno_   we have alternated times on various meeting in the past, but that's not a great solution either
17:16   liw     yeah, a constant time would be best, makes it easiest to plan ahead
17:16   liw     for me, at least
17:16   pedro_  indeed
17:16   heno_   liw: and 18.00, say, would be worse I take it
17:17   heno_   I'm an evening person, so I don't mind either way
17:17   liw     I'm UTC+2 (UTC+3 during daylight savings time), so 18 UTC would be 20 (or 21), which would mean I won't get anything else done that evening
17:17   stgraber        ^ Would be perfect for me :) but indeed I doubt liw would be happy with it
17:18   liw     especially since Wednesdays are typical days for meeting people socially
17:19   liw     so basically I'm in favor of keeping 1600 UTC
17:19   heno_   ok, with one for and one against, we'll leave it as it is for now
17:19   heno_   sorry stgraber :(
17:20   liw     stgraber, indeed, sorry
17:20   stgraber        ok, well for me as you saw the best case is 17h30 at home, usually it'll be 18h30 and then will miss the meeting
17:20   stgraber        as I was 1minute away from missing my bus :)
17:20   heno_   perhaps we should consider a community meeting sometimes on the weekend
17:21   heno_   let's see how well attended the QA-related sessions are this weekend
17:21   heno_   (arranged by the LoCo teams I think)
17:22   heno_   [AGREED] Leave the meeting time at 16.00 UTC
17:22   MootBot AGREED received:  Leave the meeting time at 16.00 UTC
17:22   heno_   can be revisited later
17:22   heno_   ok, let's stop there
17:22   heno_   thanks everyone for attending!
17:23   heno_   #endmeeting
17:23   MootBot Meeting finished at 17:23.

MeetingLogs/QATeam/20071114 (last edited 2008-08-06 17:00:05 by localhost)