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)