20080730

Log

UTC

18:01   Moot2   Meeting started at 12:04. The chair is heno.
18:01   Moot2   Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
18:01   heno    Agenda: https://wiki.ubuntu.com/QATeam/Meetings
18:01   cody-somerville \o/
18:01   cody-somerville I'm here!
18:01   heno    hey cody-somerville
18:01   ogasawara       hi everyone :)
18:02   heno    [TOPIC]: Bug Importance Guidelines
18:02   Moot2   New Topic: : Bug Importance Guidelines
18:03   heno    this was suggested by Brian on the mailing list but as stalled there
18:03   davmor2 schwuk: evening :)
18:03   LaserJock       so briefly
18:03   heno    we should poll the views of the team here and then check in with devs and release team again
18:03   LaserJock       the question is whether Importance should be per-package or per-distro
18:03   LaserJock       ?
18:04   heno    right
18:04   bdmurray        Basically yeah
18:04   LaserJock       Debian is per-package, correct?
18:05   heno    and they have the concept of RC bugs in addition
18:05   LaserJock       I'm basically for per-package Importance
18:05   davmor2 Per-package gets my vote there are some package that cross a number of distro's.
18:05   LaserJock       I know it might mean we need to redo some things
18:05   LaserJock       but for sure from a Universe perspective per-package is better
18:06   bdmurray        We have milestones and release targetting for setting distribution importance
18:06   heno    the release team uses importance as one flag denoting an RC bug in Ubuntu
18:06   LaserJock       basically anything in Universe is going to have a lower priority, by definition, than something in Main
18:06   LaserJock       which doesn't help developers trying to have useful bug lists
18:07   stgraber        I'd also +1 per-package as it's how I want to handle priority of the package(s) I maintain (sort of), that's fine as long as we have a way of clearly getting a list of RC bugs
18:07   heno    https://wiki.ubuntu.com/RCBugTargetting
18:07   bdmurray        LaserJock: you mean currently right?
18:07   LaserJock       bdmurray: right
18:07   LaserJock       in general people are looking at how important a bug is relative to the other bugs in the package
18:08   LaserJock       and we do have milestones as bdmurray said
18:08   LaserJock       bdmurray: would it be reasonable to define milestone targeting as RC?
18:08   heno    no because some people use milestones to plan their work
18:08   stgraber        btw, who can milestone bugs at the moment ? (I'm not sure how ACLs are handled now on LP)
=== Moot2 is now known as MootBot
18:09   bdmurray        stgraber: ubuntu-bugcontrol
18:09   heno    independent of the RC function
18:09   LaserJock       heno: hmm, that is a point
18:09   LaserJock       devel release targeting might be a better choice
18:10   LaserJock       or maybe Launchpad can give an RC flag to drivers or something
18:10   LaserJock       in any case, is anybody opposed to having per-package Importance?
18:11   heno    actually a combination of milestone and release targeting is the official way to denote an RC bug
18:11   heno    if it's medium priority or less, it's just a target of opportunity
18:12   LaserJock       as far as I can tell the only -1 on the mailing list thread was from mpt
18:12   LaserJock       because of Launchpad perhaps using the Importance for some bug metric
18:12   heno    I don't think that should conflict with aligning importance with the package though in real world situations
18:13   heno    real RC (high and critical bugs) are likely also high+ for that package
18:13   LaserJock       so an RC bug is defined as one that is Medium or above priority + targeted to devel release + milestoned ?
18:13   LaserJock       heno: exactly
18:13   heno    we can probably contrive situations where that is not the case, but ...
18:14   cody-somerville It is high or above
18:14   LaserJock       oh, ok
18:14   heno    we could state explicitly that the release management use of importance takes precedence
18:14   cody-somerville What if we had a ubuntu project?
18:15   heno    for the 5-per release corner cases
18:15   LaserJock       heno: sure
18:15   mpt     cody-somerville, what do you mean by an ubuntu project?
18:15   sbeattie        cody-somerville: you mean an ubuntu-release project, that the release manager(s) use to set priorrity there?
18:15   cody-somerville sbeattie, Yes.
18:16   mpt     heh, that would be such a hack
18:16   heno    I'd rather we didn't try to redefine the way RC bugs are managed here, as that was already a long discussion and has now been settled
18:16   bdmurray        the importance for the release would be set on the release task
18:17   mpt     So maybe Launchpad should be able to track a bug's importance to a distribution release separately from its importance to the package
18:17   cody-somerville There could be a Ubuntu project/product on launchpad and we can affect it for bugs that are of interest distro-wide. It makes sense to me because I see packages as individual and isolated where a "product" would represent the product Ubuntu as a whole.
18:17   ara_    and the link between ubuntu and ubuntu-release would be automatic?
18:18   LaserJock       mpt: I think we're kinda already doing that with milestones and release targeting
18:18   cody-somerville mpt, mmm... yea, that would be better than a separate product
18:18   ScottK  I think what Launchpad's future functionality may or may not be is not really on topic for a discussion of what Ubuntu policy should be currently.
18:18   mpt     true
18:18   heno    right
18:19   LaserJock       so, is there any opposition to the proposed change (Importance is defined on a per-package basis)?
18:19   heno    I think we should take a position on this and then ask the release team if that causes problems for them
18:19   LaserJock       heno: +1
18:19   heno    +1 from me
18:19   ScottK  My main concern with the change is that if we change we suddenly have all the bugs triaged wrong.
18:19   ScottK  Is there a plan to deal with that?
18:20   LaserJock       well, there is a point there
18:20   cody-somerville ScottK, We were wondering about using a separate project/product in launchpad to track bugs that are of interest to the distro (ie. "release critical") interest of trying to contrive that from the fields that are/should be representative of the package
18:20   LaserJock       I would tend to think that it would just transition over
18:20   heno    how many are really that wrong though?
18:20   bdmurray        I think it'll be handled the same way as all the Confirmed bugs when Triaged came out
18:21   ScottK  heno: For example, in Universe there are essentially no High/Critical bugs because almost by definition, if it's not in Main it can't be high.
18:21   LaserJock       my guess is that a lot of Universe or less "important" package will be able to bump up their Importance
18:21   LaserJock       but nothing should really go down in Importance
18:21   sbeattie        cody-somerville: I think what bdmurray's pointing out is that the the release manager could set the priority for the release, if it's different from the package's priority by setting the priority on the target-release task itself.
18:21   ScottK  bdmurray: I don't think that's giving me confidence.
18:21   bdmurray        I think it will be less of an issue with packages with few bug reports
18:22   heno    it think it's a bigger problem that so many bugs are without importance at all
18:22   bdmurray        It becomes more useful where you have packages with 75+ medium bugs
18:22   heno    and in New
18:22   ScottK  I think there should be a clear plan before the policy change.
* ScottK will be AFK for ~5 minutes.
18:22   LaserJock       ScottK: can the plan be we have no plan? ;-)
18:23   LaserJock       I don't think there's a way to comprehensively just re-prioritize all bugs
18:23   greg-g  or when the bug is looked at again the importance can be changed?  for smaller packages it shouldn't matter TOO much to wait a bit.  For the big projects those independent maintainers already have an idea and could do it relatively quickly
18:23   LaserJock       yeah
* cody-somerville wonders if maybe we should poke the actual release team to see if they can get in on this discussion because it is moot if the solution we come up with if it doesn't work for them.
18:24   LaserJock       I would just say "next time you touch the importance, re-evaluate it in view of the new policy"
18:24   LaserJock       cody-somerville: I don't think we're changing anything for them really, are we?
18:24   geser   I don't believe that a bug in a random package in universe will get fixed quickier because it's now High instead of just Medium or Low
18:24   davmor2 Can you not just add an RC tag that set a release critical bug flag?  An the importance be set in the general manner?
18:24   greg-g  LaserJock: ++
18:24   bdmurray        cody-somerville: I've spoken to slangasek and he was fine with it
18:25   heno    I agree with bdmurray that the place where this is an issue is the packages with lots of bugs that have been prevented from using Critical because of the current policy
18:25   LaserJock       davmor2: tags are open ACLs, *everything* would be RC ;-)
18:25   LaserJock       geser: no, but moving on in the future it might
18:25   heno    a bug in Medium that should really be in High now is not so pressing IMO
18:26   davmor2 LaserJock: Limit who can access the RC flag
18:26   cody-somerville heno +1
* cody-somerville doesn't really pay attention much to bug important anyhow.
18:26   LaserJock       davmor2: that would be a big Launchpad change, and perhaps not one they want to make
18:26   LaserJock       cody-somerville: that's the problem, IMO
18:27   LaserJock       it would be good if Importance was properly defined and used so that it does mean something to people and they pay attention to it
18:27   LaserJock       currently I don't think we have that
18:27   cody-somerville I don't see the importance field becoming overly important in most developer's workflow.
18:27   LaserJock       it should
18:28   heno    and consistency has intrinsic value in itself
18:28   LaserJock       and it's also feedback to users/reporters
18:28   geser   if I stumble about a bug I know how to fix I usually don't care about the importance
18:28   heno    ScottK: do you have any objection other that the transition period issue
* ScottK just got back. Let me read the scrollback.
18:29   heno    (there will always be that with any change of tool, policy or procedure)
18:30   cody-somerville I think we need new values for the importance field
18:30   greg-g  the consistency is a Good Thing(tm) and also, being able to do meaningful reports per package would also be useful. (to respond to the issue of importance not being imortant)
18:30   ScottK  That makes policy change pre-depend on LP change cody-somerville
18:30   cody-somerville Sorta Important, Important, and Omgz Important would mean more to me.
18:31   LaserJock       can somebody write up a greasemonkey script for cody-somerville ? ;-)
18:31   cody-somerville <g>
* cody-somerville would so use it if someone did. :P
18:31   geser   cody-somerville: Sorta Important = Low, Important = Medium, Omgz Important = High? :)
18:32   davmor2 cody-somerville: should of done it yesterday = critical
18:32   ScottK  heno: I guess I throw my hands up and say whatever.  I see the advantage of the policy change and so that's fine.  I think about the pain with the current LP speed/UI of actually doing it and I think it's not going to be me spending time on it.
18:32   heno    ok
18:32   ScottK  I'd have mapped Low to Not Important.
18:32   cody-somerville ScottK, same here
18:33   heno    let's hope the new LP APIs make all this much easier ;)
18:33   LaserJock       isn't wishlist Not Important ?
18:33   ScottK  heno: I just think when it's decided (and I think we ought to have more developer input that we have here) it needs to be clearly communicated.
18:33   ScottK  LaserJock: Wishlist is NotABug, but we don't want to say so.
18:33   cody-somerville LaserJock, Wishlist -> Illegitimate :P
18:33   heno    right. so we've settled on +1 as a QA team recommendation
18:34   cody-somerville +1
18:34   LaserJock       cody-somerville: those are Invalid
18:34   cody-somerville LaserJock, Illegal Alien then
18:34   LaserJock       moving on ...
* ScottK votes 0 - I see the advantage, but I boggle at the inhereited backlog.
18:35   heno    it's been suggested to the u-devel ML though, so there as been opportunity to weigh in
18:35   ScottK  For some better spelling of inherited
18:35   ScottK  heno: I don't think silence is concurrence is a good model for deciding policy changes.
18:35   sbeattie        ScottK: do you have suggestion  on how to deal with the backlog?
18:35   heno    bdmurray: will you work with me on a proper announcement?
18:36   ScottK  heno: I object to deciding this based on silence is concurrence.
* ScottK revises his vote to -1.
18:36   LaserJock       heno: I think sounds good to email to -devel a  "QA team is recommending we set Importance on a per-package basis, feedback on is welcome"
18:36   ScottK  I'm OK with that.
18:36   heno    ScottK: how else should we decide? should everything be taken to the TB?
18:36   cody-somerville Isn't silence abstaining?
18:37   geser   ScottK: true, but sometimes the only way to get moving forward :(
18:37   heno    LaserJock: sounds good
18:37   ScottK  sbeattie: There isn't a good answer for it.  It's just lots of work.  If we were starting from bug #2, I'd say do it this way.  I'm not certain it's worth the effort now.
18:37   davmor2 +1
18:37   LaserJock       ok, let's move on then, please :-)
18:37   heno    ok we are agreed :)
18:37   ScottK  heno: No, but "Hey let's talk about this" is different than "We intend to do this unless someone objects".
18:37   heno    [TOPIC]: ISO test bug report template
18:37   MootBot New Topic: : ISO test bug report template
18:38   davmor2 Ah this is me :)
18:38   davmor2 So when working with cgreagan on UME he had a very structured way to do bug reports.
18:39   davmor2 This was great for UME not so good for ISO's/QA a little too inflexible.
18:39   davmor2 So I started work today on my own version for Specifically ISO's
18:40   davmor2 it looks like this now after conferring with a few people
18:40   davmor2 RELEASE:
18:40   davmor2 CD/DVD VARIANT:
18:40   davmor2 ISO DATE:
18:40   davmor2 SYMPTOMS:
18:40   davmor2 CAUSE:
18:40   davmor2 STEPS TO REPRODUCE:
18:41   heno    davmor2: just to be clear: your recommendation is for ISO testing sourced bugs only - not bugs generally
18:41   LaserJock       hmm, should TEST CASE: be in there?
18:41   heno    the topic in the wiki is a bit unclear
18:41   bdmurray        steps to reproduce could be test case
18:41   heno    actually, it's not - might have been your email
18:42   LaserJock       bdmurray: no, I mean, which iso test case they found the bug in
18:42   sbeattie        davmor2: perhaps s/ISO DATE/ISO BUILD/ since there are often mutliple builds on a given day as release deadlines approach?
18:42   LaserJock       like Install (expert) or whatever
18:42   heno    yep, let's standardise on 'TEST CASE' as we already use that
18:43   LaserJock       the stuff that's in https://wiki.ubuntu.com/Testing/Cases/*
18:43   davmor2 Step's to reproduce is just the way for dev's to know what I was doing when the bug occured.
18:43   LaserJock       additionally, would it be feasible to file the bugs via the ISO tracker?
18:43   davmor2 example https://bugs.launchpad.net/ubuntu/+bug/253367
18:43   ubottu  Launchpad bug 253367 in ubuntu "Intrepid: Ubuntu screen saver kicks in then switches off again" [Undecided,New]
18:44   LaserJock       we have somewhat of an overloaded definition of "test case" here
18:44   LaserJock       Test Case = what specific test where you doing on the iso when you encountered the bug
18:45   davmor2 It makes the bug far more readable for Dev's it also means that you don't forget to add important info like version's etc.
18:45   LaserJock       Test Case = what steps are needed to test or reproduce the bug
18:46   sbeattie        davmor2: I think generally we're all in agreement that this is a good idea.
18:46   LaserJock       yeah
18:46   LaserJock       also, not sure if CAUSE: is going to be generally filled in
18:46   sbeattie        and just a matter of getting some of the details right.
18:46   heno    are there cases where 'steps to reproduce' would not serve as a test case?
18:47   LaserJock       heno: how do you mean
18:47   davmor2 I think that TEST CASES is something that should stay in the qa realms.  That step to reproduce is more general and intuitive for dev's and bug triagers
18:47   LaserJock       ok, maybe I'm not clear here
18:47   heno    if you follow these steps and you reproduce it's still there, if it doesn't occur then it's fixed
18:47   heno    that's basically a test case
18:48   LaserJock       a piece of data in the bug that is needed is what part of the build you were testing
18:48   stgraber        heno: as far as I understand, LaserJock asked if we should include the ISO tracker testcase in the bug report, something like "Install (entire-disk)"
18:48   LaserJock       this in the ISO tracker is called a test case
18:48   LaserJock       stgraber: right
18:48   heno    oic
18:48   ara_    heno, i think that is too inflexible for a test case definition
18:49   stgraber        the problem here is that "testcase" has at least two different meaning for us :)
18:49   heno    right, so we are over loading it
18:49   LaserJock       exactly
18:49   heno    ara_: heh :) can you help us with a more general definition?
18:49   davmor2 As I said I think Steps to reproduce is more intuitive in a readable format.
18:50   davmor2 as in you know what it means :)
18:50   LaserJock       right
18:50   heno    that's a good point, davmor2
18:50   LaserJock       but we are using the term "test case" elsewhere, like with SRUs
18:50   LaserJock       so I just wanted us to be aware of that
18:51   LaserJock       perhaps we need a QA Glossary :-)
18:51   heno    anyway, we are bikesheding a bit here
18:52   davmor2 LaserJock: Yes and at that point we know what it means.  However dev's, bug triagers etc don't need to know that's what we are working from they just need to know how we came about the bug :)
18:52   LaserJock       davmor2: can you put up the Template on a wiki page where we can discuss, tweak?
18:52   sbeattie        agreed. Perhaps we can just agree to include the link to the iso test case in the steps to reproduce.
18:52   ara_    sbeattie: that makes sense
18:52   heno    that works
18:52   davmor2 sbeattie: I'm also using the template for smoke tests too
18:53   LaserJock       davmor2: I disagree
18:53   heno    davmor2: will you set up a template in the wiki to start with?
18:53   davmor2 Yes no probs :)
18:53   heno    let's move on
18:53   davmor2 Be latter on though I got LUG meeting to go too any second :)
18:53   heno    [TOPIC]: Bugs in backport packages. Which should the policy with those be? It is clearly written that those packages are unsupported
18:53   MootBot New Topic: : Bugs in backport packages. Which should the policy with those be? It is clearly written that those packages are unsupported
18:54   sbeattie        davmor2: BTW, the latest dl-ubuntu-test-iso, when passed the --versions arg, will report all the build versions of the isos unser ~/iso/
18:54   sbeattie        s/unser/under/
18:54   ara_    I asked in the distro channel, about the policy with this
18:54   LaserJock       ara_: which channel?
18:55   ara_    canonical internal
18:55   LaserJock       k
18:55   stgraber        sbeattie: btw, the next revision of the ISO tracker will have a /list URL (IIRC) that'll give you the list of all images we currently have on the ISO tracker and the md5 for these
18:55   ara_    and the usual thing to do would be:
18:55   ara_    This also affects project -> select hardy-backports as project
18:56   ara_    then, if the bug also happens to be in intrepid, leave the ubuntu one open
18:56   ara_    if not, close the ubuntu bug
18:56   LaserJock       that seems reasonable
18:57   heno    then there is no longer a bug open on a real package
18:57   heno    though that may not be a problem
18:57   ara_    yep, if it only happens in the backport package and not the new release, then it is not maintained
18:57   LaserJock       if it only affects specifically the -backports package then I'm not sure what else you'd do
18:58   LaserJock       ara_: what do you mean by "maintained"
18:58   ara_    supported
* LaserJock is on a glossary hunt today
18:58   LaserJock       uh oh
18:58   LaserJock       ara_: what do you mean  by "supported" ? :-)
18:58   ara_    :)
18:58   LaserJock       these aren't trivial questions though
18:58   LaserJock       -backports is supported
18:58   LaserJock       just not by Canonical
18:59   davmor2 Right I need to get off talk to you tomorrow
18:59   LaserJock       and it is maintained, just not by Canonical specifically
18:59   stgraber        davmor2: see you
19:00   heno    is it supported by Ubuntu though? as in do we make security fixes to things in -backports?
19:00   LaserJock       sure
19:00   LaserJock       if somebody wants to do it
19:00   LaserJock       the backports team are all Ubuntu developers
19:00   heno    if nobody within the project has taken on that responsibility then it's not supported currently
19:00   LaserJock       usually official Ubuntu archives
19:01   LaserJock       so I'm not sure how it would be not supported
19:01   LaserJock       unless perhaps the backports team specifically said they weren't going to
19:01   ara_    but when you select in the Software Sources (system menu) the hardy-backports checkbox it is stated "Unsupported updates"
19:01   heno    if the backports team explicitly commits to that then perhaps. it's probably still a question for the TB though
19:02   LaserJock       heno: perhaps rather a question for the backports team
19:02   heno    yep
19:02   LaserJock       I don't know that it's an issue for the TB
19:02   LaserJock       maybe, but I suspect not
19:03   LaserJock       in any case, it's not clear what "supported" means in these contexts
19:03   LaserJock       but I'm quite sure that the backporters want to know if there are bugs in their packages
19:03   LaserJock       we had an issue with flash for instance, not long ago
19:03   heno    I think it would be for Ubuntu as a project to say 'we support packages in backports' - ie. we as a project delegate that responsibility to the backports team
19:03   LaserJock       and it was fairly clear from that discussion that the backports do try to make sure their packages are bug-free as possible
19:04   LaserJock       heno: I believe we already do say that
19:04   heno    ok, but from a practical perspective, it seems that ara's suggestion works
19:04   LaserJock       i.e. it's in our archives, and it's done by our developers, it's ours to support
19:05   heno    closing the package task with the backports task open seems fine to me
19:05   LaserJock       but, I must admit that the whole "supported" thing is still unclear to me
19:05   LaserJock       heno: totally agreed
19:05   heno    LaserJock: good point
19:06   LaserJock       we want to know if it's going to be a bug in Intrepid
19:06   heno    anyone object?
19:06   LaserJock       so it's valuable having that information
19:06   LaserJock       but if it's not, then the backporting team needs to take care of it
19:07   heno    let's move on
19:07   heno    [TOPIC]: QA Liaison to Launchpad
19:07   MootBot New Topic: : QA Liaison to Launchpad
19:07   LaserJock       ok, well in interest of time perhaps I'll just give a link to the wiki page I wrote up
19:08   LaserJock       https://wiki.ubuntu.com/JordanMantha/QALiaison
19:08   heno    I have to admit I've failed to get a suggestions list up before this meeting
19:08   LaserJock       and perhaps we can move the discussion to the mailing list this week
19:08   heno    (of LP feature requests)
19:09   LaserJock       hopefully the wiki page is fairly clear
19:09   heno    sounds good. we are running a bit long here
19:09   jonpackard      I'd like to make a small suggestion: I think it would be of great benefit to have brief information about the QA Team on the related teams' wiki pages. Mostly just about how the teams are related to the QA Team. I was a member of BugSquad and had never heard of the QA Team until I read about it on Distrowatch.com (it kind of gave the team a bad rap in some ways).
19:10   LaserJock       jonpackard: yeah, I think we can troll around the wiki for some better inter-team linking
19:10   heno    the header is a good start
19:10   LaserJock       jonpackard: perhaps you might want to add an item to https://wiki.ubuntu.com/QATeam/RoadMap ;-)
19:10   heno    we should deploy that consistently
19:10   LaserJock       jonpackard did great work on that this week
19:11   LaserJock       and also cleaning up our meeting logs
19:11   heno    rock jonpackard!
19:11   LaserJock       my inbox was full of wiki edits ;-)
19:11   jonpackard      thanks :-[
19:11   heno    thanks for stepping up to do that
19:11   heno    the QA portal should help too
19:12   jonpackard      ´╗┐heno: you're very welcome
19:12   heno    the new face of qa.ubuntu.com
19:12   LaserJock       heno: ok, last item real quick?
19:12   heno    [TOPIC]: FAUMachine for installation testing (LaserJock)
19:12   MootBot New Topic: : FAUMachine for installation testing (LaserJock)
19:12   stgraber        heno: this one got back to the "need better spec" status after discussing a bit with LaserJock the other day :)
19:13   heno    stgraber: ok :)
19:13   LaserJock       stgraber: I've also been talking with ubuntuwire.com people
19:13   heno    I believe liw looked into faumachine last year
19:13   stgraber        yeah, we had a demo of it at UDS-Boston IIRC
19:13   LaserJock       yeah, so I wanted to just bring it up
19:14   LaserJock       because I was talking with sistpoty (who is a FAUMachine dev and Ubuntu core developer)
19:14   heno    it's neat to be able to poke commands in from the outside, but it means those tests cannot be run on native hw
19:14   LaserJock       and he thought it might be useful
19:14   heno    which can be useful
19:15   heno    with the native tests we can run them in a range of envirnonments
19:15   LaserJock       sure
19:15   heno    from hw to vms
19:15   heno    VMs I should say :)
19:16   LaserJock       I wonder how easy the native hw tests are
19:16   heno    but if sispoty can make a good case for it we will listen of course
19:16   LaserJock       I haven't seen anything on what the hardware cert people are doing
19:16   heno    LaserJock: to write or run?
19:16   LaserJock       both
19:16   LaserJock       run primarily
19:16   heno    ara_: have you looked at faumachines at all?
19:16   LaserJock       what I'm getting at, is what can we give to advanced users/ubuntu devs to test for us
19:16   cr3     LaserJock: that's because it's internal for now, but we're always open to bigger better ways of doing things in concert with the community
19:17   ara_    heno: no, nothing yet
19:17   LaserJock       I'm not necessarily saying we should ditch what's being done now in favor of FAUmachine
19:17   LaserJock       but perhaps it would be a good compliment
19:17   heno    LaserJock: right. I wondering if it not better done with tests scripts in a VM though
19:17   ara_    heno: i will try to give it a try
19:18   LaserJock       heno: pardon my ignorance, but how is that done?
19:18   heno    we should perhaps ask sispoty for a demo of faumachines for this case
19:18   LaserJock       how would I do automated installation testing in a VM?
19:18   heno    ara_: perhaps just have a look
19:19   stgraber        LaserJock: preseeding is a way
19:19   LaserJock       stgraber: ok, right
19:19   LaserJock       can that handle the ISO test cases fairly well?
19:20   heno    there is some info here: https://wiki.ubuntu.com/Testing/Automation
19:20   stgraber        yep, except it doesn't test the UI
19:20   LaserJock       can you preseed the Desktop install for isntance?
19:20   cr3     LaserJock: 1. vmware provides perl scripts to talk to vmware-server for example, see vmware-ubuntu project on launchpad;
19:20   LaserJock       cr3: ok cool
19:20   cr3     LaserJock: 2. the preseeding could either be done by modifying an iso image, supported by vmware-ubuntu, or from some other location
19:21   cr3     LaserJock: that project is just a shell script wrapping some of the coolness readily avialable from the vmware command line
19:21   sbeattie        heno: when we get back to generating vm images, we should consider adding faumachine images to those we generate.
19:21   cr3     sbeattie: where do we draw the line? vmware, qemu, kvm, faumachine, etc.?
19:21   LaserJock       I'm just trying to get us from "cool stuff a QA engineer can run" to "cool stuff an Ubuntu ISO tester can run"
19:22   LaserJock       cr3: ideally all of the above ;-)
19:22   LaserJock       but the disk/bandwidth seems like it'd be unreasonable
19:22   heno    LaserJock: indeed, I would love that too
19:22   stgraber        cr3: you forogot virtualbox :)
19:22   cr3     stgraber: and the list goes on :)
19:22   heno    if faumachines is an easier way to that we should take a serious look
19:23   LaserJock       the vmware-ubuntu thing sounds cool
19:23   LaserJock       in any case, I just thought I'd bring it up
19:23   LaserJock       I can poke sistpoty about it further (I was going to try to get him to come to the meeting but he's offline)
19:23   heno    ok, ara will have a look at faumachines and sispoty is invited to present if for the team as well
19:24   LaserJock       ah, cool
19:24   heno    ok, any other urgent business?#
19:24   cr3     LaserJock: before you get too excited, I wrote that on the corner of the table but it enables me to automatically install new vmware instances from any alternate image for example
19:24   stgraber        Just a quick notice, I have worked on the Drupal module for the Package status, the result can be seen here: http://80.83.51.125/qapkgstatus/openoffice.org
19:24   stgraber        It's just rendering ogasawara's xml files. Comments/suggestions are welcome.
19:24   LaserJock       cr3: something is better than nothing
19:25   heno    stgraber: excellent!
19:25   LaserJock       I'm looking for things we can put effort into
* heno cheers ogasawara and stgraber
19:25   ara_    stgraber: neat!
19:25   ogasawara       I'll try to tackle some of the feature requests and add them to the xml
19:25   LaserJock       stgraber: is that "live"?
19:25   sbeattie        stgraber: a popup bug info for the oldest bugs a la the way the most duplicates bug is handled might be nice, too,.
19:26   ogasawara       will also want to start generating more xml files for other packages
19:26   ogasawara       sbeattie: I'll add that to the list
19:26   stgraber        LaserJock: sort of, when it'll be on qa.ubuntu.com it'll be. At the moment I just sync the .xml file when ogasawara tells me she changed something.
19:26   LaserJock       stgraber: k
19:27   LaserJock       well that is just a really cool page
19:27   stgraber        ogasawara: would be good so we can use those categories :)
19:27   ogasawara       stgraber: exactly :)
19:27   heno    the xml may be useful for other people too, can we link to that?
19:27   ogasawara       sure, just a sec
19:27   stgraber        http://people.ubuntu.com/~ogasawara/pkg-stats/openoffice.org.xml
19:27   MootBot LINK received:  http://people.ubuntu.com/~ogasawara/pkg-stats/openoffice.org.xml
19:28   heno    I mean on the web page :)
19:28   LaserJock       ogasawara: oh, that is very interesting
19:28   heno    as in data source: LINK
19:29   stgraber        heno: sure
19:29   stgraber        ogasawara: can you add a link to the original .xml (on people.u.c) and the generation time to the .xml ?
19:29   ogasawara       stgraber: sure
19:29   LaserJock       ogasawara: is the code for that publicly available?
19:30   stgraber        ogasawara: as attribute of <package> should be fine
19:30   ogasawara       LaserJock:  I
19:30   ogasawara       LaserJock: heh, I'll clean up the code and check it into bzr
19:30   ogasawara       stgraber: ok
19:30   LaserJock       ogasawara: very cool, very cool indeed :-)
19:31   heno    ok, we've been going for 1h30 now so let's wrap it up
19:31   heno    cool stuff though!
19:31   heno    #endmeeting
19:31   MootBot Meeting finished at 13:34.
19:31   ara_    ok, thanks guys!
19:31   greg-g  wow, long meeting ;)
19:31   heno    thanks everyone, good meeting!
19:31   ara_    cheers!
19:32   sbeattie        thanks, everyone.
19:32   stgraber        thanks

MeetingLogs/QATeam/20080730 (last edited 2008-08-06 16:59:49 by localhost)