| === elkbuntu is now known as elky | ||
| === thekorn is now known as thekorn_ | ||
| === ogra_ is now known as ogra | ||
| === RoAk is now known as RoAkSoAx | ||
| pedro_ | hey hey hey! | 18:00 |
|---|---|---|
| heno | hey! | 18:00 |
| * nand waves | 18:00 | |
| davmor2 | hello pedro_:) | 18:00 |
| ara_ | hello! | 18:00 |
| * stgraber waves | 18:00 | |
| pedro_ | hey davmor2 :-) | 18:00 |
| sbeattie | Hey all! | 18:00 |
| heno | welcome back pedro! | 18:00 |
| * bdmurray waves | 18:00 | |
| greg-g | good morning | 18:00 |
| pedro_ | heey heno, thanks ;-) | 18:00 |
| heno | #startmeeting | 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:01 |
| heno | [TOPIC]: Bug Importance Guidelines | 18:02 |
| Moot2 | New Topic: : Bug Importance Guidelines | 18:02 |
| 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:03 |
| heno | right | 18:04 |
| bdmurray | Basically yeah | 18:04 |
| LaserJock | Debian is per-package, correct? | 18:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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) | 18:08 |
| === Moot2 is now known as MootBot | ||
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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. | 18:22 |
| * ScottK will be AFK for ~5 minutes. | 18:22 | |
| LaserJock | ScottK: can the plan be we have no plan? ;-) | 18:22 |
| 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 | 18:23 |
| * 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:24 |
| 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:25 |
| davmor2 | LaserJock: Limit who can access the RC flag | 18:26 |
| cody-somerville | heno +1 | 18:26 |
| * 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:26 |
| 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:27 |
| 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 | 18:28 |
| * 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:29 |
| 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:30 |
| LaserJock | can somebody write up a greasemonkey script for cody-somerville ? ;-) | 18:31 |
| cody-somerville | <g> | 18:31 |
| * cody-somerville would so use it if someone did. :P | 18:31 | |
| geser | cody-somerville: Sorta Important = Low, Important = Medium, Omgz Important = High? :) | 18:31 |
| 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:32 |
| 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:33 |
| cody-somerville | +1 | 18:34 |
| LaserJock | cody-somerville: those are Invalid | 18:34 |
| cody-somerville | LaserJock, Illegal Alien then | 18:34 |
| LaserJock | moving on ... | 18:34 |
| * ScottK votes 0 - I see the advantage, but I boggle at the inhereited backlog. | 18:34 | |
| 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:35 |
| ScottK | heno: I object to deciding this based on silence is concurrence. | 18:36 |
| * 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| LaserJock | perhaps we need a QA Glossary :-) | 18:51 |
| heno | anyway, we are bikesheding a bit here | 18:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| LaserJock | ara_: what do you mean by "maintained" | 18:58 |
| ara_ | supported | 18:58 |
| * 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:58 |
| 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 | 18:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| heno | stgraber: excellent! | 19:25 |
| LaserJock | I'm looking for things we can put effort into | 19:25 |
| * 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| sbeattie | thanks, everyone. | 19:32 |
| stgraber | thanks | 19:32 |
| === tonohono_ is now known as tonohono | ||
| Riddell | Kubuntu meeting in a couple of minutes in #kubuntu-devel | 22:59 |
| cjwatson | good evening | 23:00 |
| * cjwatson pokes the bot in the vain hope of it knowing about the platform team meeting | 23:00 | |
| calc | hello | 23:00 |
| TheMuso | Hey all. | 23:00 |
| liw | greetingses and salutationses | 23:00 |
| james_w | hi all | 23:01 |
| * cjwatson moves to cooler surroundings - must get that hot water tank lagged so that it stops spraying heat all over the top of the house | 23:01 | |
| TheMuso | haha | 23:02 |
| TheMuso | sounds... unpleasant. | 23:02 |
| james_w | cjwatson: do we need a new batch of meetings scheduled on the fridge? | 23:02 |
| * ogra waves | 23:02 | |
| james_w | hi all | 23:02 |
| === claydoh_ is now known as claydoh | ||
| cjwatson | james_w: yeah, I'll e-mail them again in a bit | 23:03 |
| cjwatson | anyway, sorry for the lack of e-mailed agenda this week, but there isn't really anything of great complexity | 23:03 |
| james_w | cjwatson: ok, thanks | 23:04 |
| bryce | heya | 23:04 |
| cjwatson | thank you for holding the meeting last week while I was trying to get my respiratory system back in order | 23:04 |
| cjwatson | since there were several absences, I wanted to go over our collective to-do list for intrepid again and cover the gaps | 23:04 |
| cjwatson | there were also a few things people didn't mention that I would have asked them about :-) | 23:05 |
| cjwatson | ArneGoetje: glad to hear the language-selector work is going well; I'm curious as to how the font-selector work is progressing, since I didn't get a chance to talk with you and James about that at the sprint | 23:06 |
| * doko will improve his mind reading next time ;) | 23:06 | |
| cjwatson | ArneGoetje: (you and I also missed out on sitting down and sorting out generation of translation statistics, which we need to get to at some point) | 23:07 |
| cjwatson | hmm, looks like Arne isn't here | 23:09 |
| cjwatson | asac is at the Firefox Summit, so I expect is also absent | 23:09 |
| cjwatson | bryce: we talked about xorg-input-hotplug earlier today, although can recap for the record if you like | 23:10 |
| cjwatson | bryce: it's low priority, but have you got anywhere with xorg-ctrl-alt-backspace? | 23:10 |
| bryce | I discussed xorg-ctrl-alt-backspace with debian, and worked out some ideas on an implementation plan | 23:11 |
| bryce | I think it's doable by FF, but like you say it's lower priority so may get bumped to intrepid+1 | 23:11 |
| cjwatson | what did the Debian X team think? | 23:11 |
| bryce | but I'd like to have something proof of concept ish by FF | 23:11 |
| bryce | surprisingly they were open to the idea | 23:12 |
| bryce | gave some suggestions on how to do the timed delay check thingee, which is the only bit I wasn't sure about | 23:12 |
| cjwatson | the required changes seem spread somewhat all over the shop, but it doesn't seem all that large or invasive | 23:12 |
| cjwatson | so I'd guess a proof of concept will not be all that far away from production code | 23:13 |
| bryce | right | 23:13 |
| bryce | regarding xorg-input-hotplug, when timo gets back the plan is to flip it on and start testing. keyboard will take some extra work, as we discussed this morning | 23:13 |
| bryce | the plan there is that I'm going to make a script that translates the console-settings config into an fdi file, which I *think* is going to be quite straightforward. And then hook it in to run with xorg-server.postinst. | 23:14 |
| bryce | so that's definitely going to be done by FF. | 23:14 |
| bryce | there is a concern that the keyboard hotplug will introduce too many issues; but the fallback here is to switch to only using input-hotplug for !keyboard. We can make that decision and change post-FF if/when needed. | 23:15 |
| bryce | not a spec, but mdz also spent time with pitti and I at the sprint about apport for xorg-server | 23:16 |
| cjwatson | has there been a chance to do any testing on tablets, touchpads, etc.? | 23:16 |
| bryce | I plan to have that work done and uploaded by FF as well. | 23:16 |
| cjwatson | that's good news, mdz was asking me about that earlier today :) | 23:16 |
| bryce | not yet, but people have been slipping me tablets to test with (a total of 4 now) | 23:17 |
| ogra | i have some tablets and at least one touchpad (a second one the next days) | 23:17 |
| tjaalton | cjwatson: it's been done on F9 already, so apparently it works (the fdi file only tells which driver to load) | 23:17 |
| tjaalton | hi btw :) | 23:17 |
| bryce | heya tjaalton | 23:17 |
| ogra | tjaalton, how do they do the calibration ? | 23:18 |
| tjaalton | ogra: how is it done now? | 23:18 |
| ogra | usually all touchpads need that ... most tablets as well | 23:18 |
| ogra | manually in a painful way ... and then editing the xorg.conf | 23:18 |
| tjaalton | ok.. input device properties will be the salvation there | 23:19 |
| bryce | x-testing-infrastructure is also on the todo list, although nothing is being uploaded so probably not required for FF. However I want to get something functional and usable by around FF or within a couple weeks after. | 23:19 |
| ogra | for tuchscreens you usually use the well hidden tool evtouch ships | 23:19 |
| cjwatson | tjaalton: input device properties landed about three weeks ago in master, I seem to remember - they aren't going to land for intrepid surely? | 23:20 |
| ogra | (/usr/lib/xf86-input-evtouch/ev_calibrate) | 23:20 |
| tjaalton | cjwatson: probably not, unless it's backported for 1.5. anyway, there is no support for synaptics yet, so it's not that useful now | 23:21 |
| cjwatson | ok, thanks bryce | 23:22 |
| cjwatson | calc: thanks for the note (and discussion) about OOo 3.0's slight slip | 23:22 |
| cjwatson | calc: I was also curious whether you'd made any progress on building a development package sufficient to build the langpacks without rebuilding the whole of OOo, and about how the discussion with the printing folks went | 23:23 |
| calc | cjwatson: i am a bit delayed on the langpack work, going to get 3.0b2 into openoffice-pkgs ppa tonight (or early tomorrow) and then will be looking at langpacks | 23:24 |
| calc | cjwatson: i managed to actually miss the printing discussion at the sprint due to email delays | 23:25 |
| calc | cjwatson: it was sent out about 20m before the dicussion and the email server seemed to eat it for a few hours apparently | 23:25 |
| calc | so i still need to talk to Till and find out what i need to be doing there | 23:26 |
| calc | wrt the 3.0 delay if it slips much more it is questionable whether it will be a good idea to push it into intrepid | 23:26 |
| cjwatson | feel free to expense an international phone call if it will make things easier, obviously | 23:26 |
| cjwatson | (for Till) | 23:27 |
| calc | 3.0rc1 is currently expected to be released on Aug 20 and 3.0 on Sept 16 | 23:27 |
| calc | ok, i have cheap voip for calls so its not a big issue for that | 23:27 |
| cjwatson | I agree that the delay is getting worrisome | 23:27 |
| calc | i somehow doubt they will go from rc1 to release in under 1 month | 23:27 |
| cjwatson | it's not quite at the OMG IMPOSSIBLE stage yet | 23:27 |
| calc | it was about 6 weeks from rc1 to release for 2.4.0 | 23:28 |
| calc | which if that happens again it will put the release ~ Sep 30 which is after beta freeze | 23:28 |
| cjwatson | a good-quality set of PPA packages would make the decision easier :-) | 23:29 |
| calc | yes, i will be uploading those RSN, just need to fixup the launchpad-integration patch | 23:29 |
| cjwatson | ok, thanks | 23:30 |
| calc | so if they don't slip anymore it would ideal since it would put the uploads right before FF and BF | 23:30 |
| cjwatson | evand is off-site at a meeting | 23:30 |
| cjwatson | james_w: can you give a summary of how font-selector work at the sprint went, since Arne's not here? | 23:30 |
| james_w | sure | 23:31 |
| james_w | we had a discussion where Arne taught me about font issues, and the sort of thing that he would like to provide a GUI configuration tool for | 23:31 |
| james_w | we then looked at fontconfig to see what that could tell us about what it was doing, and we realised the answer was not that much | 23:32 |
| james_w | so to do everything Arne wants would require extending fontconfig to expose this information, or re-implementing the configuration files logic | 23:32 |
| james_w | however, it seemed like allowing the user to set the font priority for each meta-font was something that could be done with no fontconfig modification, so we're going to try and do that in the Intrepid timeframe. We're not going to have anything worthy of being in main or on the CD for this release though | 23:34 |
| slangasek | is the fontconfig mod the better long-term design? | 23:34 |
| slangasek | (does it help if I bend Keith's ear sometime?) | 23:34 |
| james_w | Arne has a glade file for a UI for this part, we now need to wrap fontconfig so we can get at it from python, and make the UI do something | 23:35 |
| james_w | slangasek: I would much prefer that, but I don't think were any where near the stage of specifying what we want. Arne could draw up a list of things that we would like to be able to do though. | 23:35 |
| slangasek | ok | 23:36 |
| cjwatson | right, that's pretty clear, thanks | 23:36 |
| cjwatson | james_w: 76 failures left is good news - is that across the whole archive, or just main? | 23:36 |
| james_w | so, I think we're blocked on me learning pyrex or similar at the moment I think. This is a low prio spec, and low priority for the both of us though isn't it? | 23:37 |
| cjwatson | it's medium priority I believe | 23:37 |
| cjwatson | but definitely background activity for you compared to udd | 23:37 |
| james_w | ok | 23:37 |
| james_w | 76 failures on the whole archive. | 23:37 |
| ogra | wow | 23:37 |
| liw | james_w, congratulations (I'm going to have to invent new ways to torture bzr...) | 23:38 |
| cjwatson | when you said encoding, that's mostly commit message encoding rather than file name encoding? (I know there are a few of the latter, but I wouldn't have expected 76) | 23:38 |
| james_w | I'm spending a lot of time on making sure we get native->non-native and back transitions correct, as this is something that won't cause failures, but just bad data | 23:38 |
| james_w | it's probably in thirds, 25 commit message encoding mistakes, 25 path issues (usually encoding), and 25 other | 23:39 |
| cjwatson | do you know where the LP folks are with exposing a namespace for these branches? | 23:40 |
| james_w | I need to focus on the client side for a while soon though, as that is impacted by FF. | 23:40 |
| james_w | I was told it was definitely post LP 2.0, so any day now :-) | 23:41 |
| cjwatson | yes, we are living in the future | 23:41 |
| james_w | I haven't spoken to jml in a while, but I doubt that he has any more news for us. | 23:41 |
| james_w | I'll make sure to raise it before they start post 2.0 planning | 23:41 |
| cjwatson | it was "we won't even plan this until after 2.0" last I checked, was just wondering if there was anything new | 23:42 |
| cjwatson | it's already on kiko's 3.0 plan | 23:42 |
| cjwatson | number one for codehosting | 23:42 |
| james_w | and we're almost at the point of saying "we're ready to start, we're just waiting for the lp changes" | 23:42 |
| cjwatson | at least if the mail I have is any guide, which it may not be | 23:42 |
| james_w | ah, that's good to know. | 23:42 |
| cjwatson | client changes will of course be of benefit to those of us already maintaining packages in bzr | 23:42 |
| cjwatson | all right, thanks | 23:43 |
| cjwatson | ogra: ISTR there's one last bit of compcache to land | 23:43 |
| james_w | yeah, there may be some bumps if you use builddeb as I switch things over, but it's for the better I promise | 23:43 |
| ogra | yeah, sorry i didnt get to that yet, i would have loved to have it in before the last alpha, especially since its no biggie | 23:44 |
| cjwatson | ogra: can we get it for alpha 4? (if necessary by you dropping what you have over to somebody else, if you're slammed with cmpc) | 23:44 |
| ogra | i'll try to get it done this week, the cmpc bugfixing went better than expected yet | 23:44 |
| cjwatson | I really want to see the memory requirement changes and figure out how much more we need to do to meet useful goals there | 23:44 |
| ogra | alpha 4 is aug. 14th ? | 23:45 |
| ogra | that should be easily doable | 23:45 |
| cjwatson | a few weekends ago I had a fairly serious go at profiling localedef and making it use much less memory, so if necessary that could be dusted off | 23:45 |
| cjwatson | yes | 23:45 |
| ogra | its really only one casper script i assume its not even more than 10 lines | 23:46 |
| ogra | the big bits are all in intramfs | 23:46 |
| ogra | and tehse are done | 23:46 |
| cjwatson | right, just needs to happen. ask for help if you need somebody to do testing legwork | 23:46 |
| ogra | i will | 23:46 |
| ogra | i cant predict anything for my other specs though, the cmpc future is very blurry atm | 23:47 |
| cjwatson | they are not high priority from my POV | 23:47 |
| ogra | (it was agreed that i dont do the atom image, but now it seems to be in discussion for me again) | 23:47 |
| cjwatson | though Benedict is getting to the age where I might start caring about local-content-filter personally at some point ;-) | 23:47 |
| ogra | heh | 23:47 |
| cjwatson | ok, this all sounds reasonably plausible when added to the material from last week, so thanks folks | 23:48 |
| ogra | well, he might be able to wait one release wit his step daddy looking over his sholder for another 4 months | 23:48 |
| cjwatson | any other business? | 23:48 |
| liw | I have a question | 23:48 |
| cjwatson | ask away | 23:48 |
| calc | opendns is pretty decent | 23:49 |
| liw | what's the usual way in Ubuntu development to get people to try out your new, fancy software to eat up people's systems if in case it's buggy? set up a PPA and ask for volunteer victims? | 23:49 |
| slangasek | opendns is RFC broken | 23:49 |
| slangasek | die die | 23:49 |
| slangasek | <ahem> | 23:49 |
| bryce | liw, yup | 23:49 |
| * ogra claps hands for slangasek | 23:49 | |
| heno | liw: ask in the forums ;) | 23:50 |
| slangasek | calc: please don't promote the use of systems that break Windows browsing on the local network :-) | 23:50 |
| cjwatson | liw: well, there's the forcible approach for the brave, stick it in the archive and arrange that no intrepid users can avoid it | 23:50 |
| cjwatson | liw: doesn't work so well for applications though | 23:50 |
| cjwatson | liw: "targeted advertisement" is really the only way to do it - I'd suggest ubuntu-devel and possibly the forums | 23:50 |
| liw | I'll have to learn about the forums... ok, thanks | 23:51 |
| ogra | probably ubuntu-users but with a warning | 23:51 |
| cjwatson | definitely arrange for there to be a built package somewhere (a PPA is the most straightforward) - most of the people you want won't build from bzr | 23:51 |
| ogra | thats the biggest list we have | 23:51 |
| liw | I was actually thinking just #ubuntu-devel to start with, but the mailing list and forums are probably a good second step | 23:51 |
| ogra | liw, also blog about it :) | 23:52 |
| liw | ogra, I have about two readers, counting myself :) | 23:52 |
| ogra | liw, time for planet then :) | 23:52 |
| cjwatson | liw: lesson learned from ubiquity: if you think your program is liable to be at all crashy, make sure to give it an apport hook so that you get information you need without having to round-trip | 23:52 |
| cjwatson | liw: https://wiki.ubuntu.com/Apport/DeveloperHowTo | 23:53 |
| liw | cjwatson, I'm not expecting it to be crashy, I'm expecting it to remove people kernels, wipe their filesystems, and send their hidden porn collections to their mothers... | 23:53 |
| bryce | liw, to get into the planet, there's a bzr repo you pull and add your feed into. Fairly straightforward. | 23:53 |
| liw | but yeah, apport, I'll put that on the list | 23:53 |
| cjwatson | liw: you could make it crash rather than actually do anything ;-) | 23:53 |
| liw | bryce, there's restrictions on who are allows on planet, though, I think | 23:54 |
| ogra | heh | 23:54 |
| bryce | liw: fwiw, I find I get more testers if I provide hardy debs | 23:54 |
| cjwatson | anyone in ~ubuntumembers can add themselves to planet; there's also precedent for sponsoring others onto planet | 23:54 |
| ogra | wow, thats brave for X | 23:54 |
| cjwatson | (viz. I did it before and nobody objected) | 23:54 |
| liw | I'm not in ~ubuntumembers yet (please don't point at me and laugh at my failings as a sapient being) | 23:55 |
| liw | but I can ask others to blog about it, I'm sure :) | 23:55 |
| liw | (I think we're done with this topic, I have my answer) | 23:56 |
| james_w | I have a quick (canonical) one, when does our holiday year run to? | 23:56 |
| cjwatson | the other thing I should note is that there is a public 8.10 status meeting tomorrow at 1600 UTC, all welcome though not required | 23:56 |
| cjwatson | james_w: calendar year | 23:56 |
| TheMuso | Good, as thats a little late for me. :p | 23:57 |
| james_w | cjwatson: thanks, I better plan some trips then | 23:57 |
| cjwatson | james_w: the company handbook is good for this kind of thing, https://wiki.canonical.com/PoliciesAndProcedures | 23:57 |
| james_w | ah, thanks | 23:57 |
| cjwatson | any more for any more? | 23:58 |
| * cjwatson bangs the gavel, adjourned, cheers | 23:58 | |
| bryce | thanks | 23:59 |
| TheMuso | Thanks. | 23:59 |
| ogra | thanks | 23:59 |
| * doko waves, and heads to bed | 23:59 | |
| * cjwatson goes back to poking bzr fast-import | 23:59 | |
| * TheMuso heads to get breakfast. | 23:59 | |
| james_w | bye all | 23:59 |
| liw | thanks, and bye | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!