| charlie-tca | All of xubuntu is done. everything passes on hardware | 01:10 |
|---|---|---|
| charlie-tca | good night. | 01:11 |
| === bladernr_ is now known as bladernr_afk | ||
| === yofel_ is now known as yofel | ||
| brendand | gema - do you reckon it would be good to have an 'introductory' email for people like besi, who 'announce' themselves on the list? | 13:22 |
| gema | brendand: what do you mean? | 13:23 |
| brendand | gema - i could respond with a few suggestions for him, but it would be good to have a uniform response which we can improve upon | 13:23 |
| brendand | gema - something like: | 13:23 |
| brendand | * irc channels | 13:23 |
| brendand | * wiki resources | 13:23 |
| brendand | * current activities (e.g. if alpa testing is running atm) | 13:23 |
| brendand | just a suggestion | 13:24 |
| gema | brendand: by all means, have a go at writing it :) our wiki is poor at the moment, make that clear, though, that one of the tasks in our list is to improve it :D | 13:24 |
| gema | brendand: I am relying on whoever jono hires to be the QA community coordinator to start putting those things together :D | 13:25 |
| gema | brendand: looks really good, like a small starter's guide, thanks | 13:30 |
| brendand | gema - no problem. it would be good to keep it somewhere and update it with extra stuff | 13:32 |
| brendand | gema - as i recall from my Symbian days, mailman supports a 'introduction email'. who controls the ubuntu-qa list? | 13:32 |
| gema | brendand: no idea | 13:33 |
| brendand | gema - i bet it's hggdh | 13:33 |
| gema | brendand: we can ask him when he comes online | 13:33 |
| brendand | jibel - i know you're a very busy man at the moment, but do you have admin access to ubuntu-qa mailing list? | 13:34 |
| jibel | brendand, yes why ? | 13:41 |
| brendand | jibel - ^ | 13:42 |
| brendand | jibel - i wanted to know if there's an 'introduction mail' option in the mailman interface | 13:43 |
| * jibel looking | 13:43 | |
| jibel | hggdh, can you help, I lost access again | 13:45 |
| jibel | brendand, sorry I eat the password again, we'll have to wait for Sir Carlos | 13:51 |
| hggdh | brendand, jibel: I have never seen an 'introduction email', or similar, in mailman | 13:54 |
| hggdh | jibel: just a sec, and I will get the passphrase | 13:54 |
| jibel | brendand, gema mailman has an autoresponder feature but nothing powerful | 14:05 |
| brendand | jibel - ok then | 14:06 |
| === bladernr_afk is now known as bladernr_ | ||
| brendand | has anyone seen that the 'camera' function of the profile picture chooser doesn't work if the installer is launched in the live session? maybe it's just my hardware | 14:21 |
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| cr3 | nerochiaro: welcome to #ubuntu-testing! :) | 16:49 |
| nerochiaro | cr3: :) | 16:49 |
| cr3 | salem_: you too, I didn't recognize your nick :) | 16:50 |
| roadmr | hey folks! | 16:50 |
| salem_ | cr3, hey, thanks! sorry about the conference. My internet connection is for some reason loosing some packages, so I couldn't hear you very well. | 16:51 |
| nerochiaro | salem_: ah, different nick on here :) | 16:52 |
| nerochiaro | salem_: you're tiagosh on canonical's servers | 16:52 |
| cr3 | salem_: that's alright, roadmr did most of the talking so I'm not offended at all :) | 16:52 |
| roadmr | hehe no problem | 16:52 |
| salem_ | nerochiaro, yes, this is an old nick from freenode. i think tiagosh is already taken here | 16:52 |
| cr3 | roadmr: should one of us follow up by email about the next steps, just to keep a paper trail to which we can point... and laugh, of course | 16:53 |
| roadmr | cr3: sure, I'm working on it right now :) | 16:53 |
| cr3 | salem_: if you decide to pick a more permanent nick on freenode, you might like to register it with nickserv to prevent the same thing from happening again | 16:53 |
| nerochiaro | and keep everyone of us in the meeting in CC | 16:53 |
| nerochiaro | so roadmr it looks like salem_ didn't get hear most of the meeting. i briefly recapped it for you, but it'd be great if you guys can go ahead and discuss what's missing here | 16:56 |
| salem_ | nerochiaro, ok, thanks | 16:57 |
| roadmr | nerochiaro, salem_ ok | 16:57 |
| salem_ | I am taking a look at the mockups and check if it is doable with the current code layout | 16:59 |
| roadmr | salem_: it's just a general idea, the mockups are based on ubuntu-one-client | 17:02 |
| roadmr | salem_: some of the stuff there is no longer needed, for instance, the "only system information" checkbox is probably no longer needed as it generates non-useful submissions | 17:03 |
| cr3 | roadmr: does the backend support the concepts illustrated in the mockups yet? | 17:03 |
| roadmr | salem_: also the document I posted (let me know if you don't have it) has some use cases we'd like the UI to cover, these are not obvious from looking at the mockups | 17:03 |
| roadmr | cr3: there are some that aren't supported :( like the global progress indicator | 17:04 |
| roadmr | cr3: some are just setting properties (like how we preseed the launchpad email account) | 17:04 |
| salem_ | roadmr, I dont have it yet I guess. can you send me? | 17:05 |
| cr3 | roadmr: I'd make sure to clarify what can be implemented now compared to what might be blocked by future implementation to make life easier on salem_ | 17:05 |
| roadmr | cr3: and some may need both backend and UI support (like the submission saving feature) | 17:05 |
| roadmr | salem_: no problem: https://docs.google.com/a/canonical.com/document/d/1gr8NiC_d2E5kuh1NVCdwIXLnm3HQZiwrl3nbYDLSCSg/edit?authkey=CLC2698I&hl=en_US | 17:05 |
| cr3 | roadmr: I don't think the UI interface supports setting properties either and it would be sad if each UI set properties its own way | 17:05 |
| cr3 | roadmr: otherwise, if I set my launchpad email in the GTK interface I probably won't get it in the Qt inteface... unless the backend provides that functionality through the user interface layer | 17:06 |
| roadmr | cr3: ok so maybe we will have to extend the interface :( | 17:06 |
| roadmr | cr3: how does the current gtk interface handle e.g. setting the launchpad id? | 17:07 |
| roadmr | cr3: I guess I could go look at the code :) | 17:07 |
| cr3 | roadmr: we will, but my concern is to avoid asking salem to implement features that are currently incomplete which makes development rather difficult | 17:07 |
| roadmr | cr3: well yep, you're right about that... | 17:07 |
| cr3 | roadmr: would a reasonable first step to get a Qt interface at par with the current GTK interface, or do you think that would be a waste of time? | 17:08 |
| cr3 | err, would it be a reasonable... | 17:08 |
| roadmr | cr3: well it depends, if it'll take salem_ a month it may not be worth it, we could ask him I guess :) | 17:09 |
| roadmr | cr3: it could be useful for him to get acquainted with how to interface with checkbox | 17:09 |
| cr3 | roadmr: for the launchpad email, the user interface layer just has a show_entry method which takes text and a default value as parameter and returns the entered launchpad email | 17:10 |
| cr3 | roadmr: in other words, it's a generic method for prompting the user for text, not specific to the launchpad email at all | 17:10 |
| cr3 | roadmr: exactly, I think just getting at par would be a nice acquaintance step | 17:11 |
| cr3 | salem_: have you had an opportunity to look at checkbox a bit, at checkbox_gtk/gtk_interface.py in particular? | 17:11 |
| roadmr | salem_: does this sound reasonable to you? come up with a feature-equivalent UI of the current checkbox-gtk but using Qt? | 17:12 |
| salem_ | cr3, yes, I created a qtinterface already | 17:12 |
| salem_ | cr3, dummy, but seems to work | 17:12 |
| roadmr | salem_: warning: the current gtk_interface.py uses a dialog as its main window, and I think we should change that, as the dialog has been a bit troublesome as of late :) we should use a window as the top-level element | 17:12 |
| cr3 | salem_: awesome, would you mind pushing those, perhaps to lp:~tiagosh/checkbox/qt | 17:12 |
| salem_ | cr3, implemented just the show_info() and seemed to work | 17:13 |
| roadmr | yay, salem_ is the man! | 17:13 |
| cr3 | salem_: how do you feel about the design so far, straightforward enough to work on? | 17:13 |
| salem_ | roadmr, haha, no, it was just a prototype, not the whole implementation :) | 17:13 |
| cr3 | salem_: once you implement all the show_* methods, the interface should be feature complete | 17:15 |
| salem_ | cr3, well, my only concern is that, if I understood correctly, the backend controls the UI, and not the other way round, so depending on the new interface, we would need to change some bits. | 17:15 |
| cr3 | salem_: very perceptive but I have to admit I'm not sure how the new interface will work, ie whether the backend will continue driving or whether the interface will take over | 17:16 |
| salem_ | cr3, sure, I can push to a branch | 17:16 |
| cr3 | salem_: for now, I think it would be safest to assume the backend is driving until we know for sure what will happen next | 17:16 |
| cr3 | roadmr: ^^^ sound reasonable to you? | 17:16 |
| roadmr | cr3: sure | 17:17 |
| cr3 | salem_: by the way, I came up with this separation between backend and frontend specifically to support multiple frameworks, originally gtk and command line but I was also thinking about qt back then. | 17:18 |
| salem_ | cr3, I can implement the full qt interface, no problem. but if the goal is to have a different concept of UI, maybe all could use the time to define the new UI, and check what needs to be changed. But this is up to you. | 17:18 |
| cr3 | salem_: I tried really hard to inspire myself from other projects which might have the same requirements but I couldn't find any, so I came up with my own design for separating the backend and frontend. | 17:19 |
| cr3 | salem_: if you happen to know of a project that does a good job of this kind of separation, please let me know because I would certainly like to learn from other people's experience | 17:19 |
| roadmr | cr3: maybe coming up with a way to let the UIs set config values would cover most of the extra functionality we need? that may not be so intrusive to the current contract | 17:20 |
| salem_ | cr3, yes, I must say this is a nice UI abstraction idea, but if the UI is going to control the data flow, and not the opposite, maybe we would need to do some adjustments. | 17:20 |
| cr3 | roadmr: indeed, this is something I can easily see being specific to graphical interfaces and the command line interface would keep working, modulo setting properties which are typically done in configuration files anyways | 17:20 |
| cr3 | salem_: we'll have to see, but maybe we can just add one method for the frontend to call the backend for setting properties as suggested by roadmr, and that might cover everything planned for 12.04 | 17:21 |
| skaet | Alpha 1 is released now. Just wanted to say thank you to everyone who's helped with testing it out and getting it ready to release. :) | 17:21 |
| salem_ | cr3, are you still going to need many UI's? or the idea is to drop the others UI abstractions (gtk, urwid)? | 17:22 |
| cr3 | salem_: in other words, it is most likely that the work we plan to invest in the Qt interface will remain as such in the foreseeable future | 17:22 |
| cr3 | salem_: unless we can find one UI to rule them all, the plan is to keep the other ones | 17:22 |
| roadmr | cr3: other than that, exposing the job store (for the progress bar), and some way of handling submission saving/renaming, and submitting an existing .xml | 17:22 |
| cr3 | salem_: I've been toying with the idea of using the SDL with pygame as a UI to rule them all, but that hasn't been received very well by some :) | 17:23 |
| * roadmr likes the pygame idea | 17:23 | |
| cr3 | roadmr: those are likely to be implemented as methods *in addition to* the existing UI methods, which might result in minor changes | 17:23 |
| salem_ | cr3, got it, so in that case, the current layout is good. We just need maybe to extend/modify some methods of the api, and adjust the others frontends accordingly | 17:24 |
| cr3 | roadmr: please consider changing the current design between the backend and frontend, I don't necessarily want to force the current design by making it painful to move forward :( | 17:24 |
| salem_ | the best way to do that is to implement a passive backend, that responds to UI commands | 17:25 |
| roadmr | cr3: sure, if some feature needs interface changes I think it's ok | 17:25 |
| cr3 | salem_: exactly, and this is likely to happen incrementally feature by feature. for example, we'll eventually add a feature to save the output in a specific location, so we'll then have to extend/modify the interfaces accordingly | 17:25 |
| cr3 | salem_: agreed, so I suspect we'll have a passive interface to enable the frontend to drive the backend and keep the current active interface, for lack of a better word, to continue having the backend drive the workflow of the frontend | 17:27 |
| salem_ | roadmr, how complex is the backend? what are the jobs the backend is in charge of? running the selected scripts, get the output of each one? what else? | 17:28 |
| cr3 | salem_: the backend does a fair amount of work | 17:30 |
| roadmr | salem_: most of the behavior is implemented through plugins that register methods to be fired on events | 17:30 |
| cr3 | roadmr: I was thinking that the frontend could interact with the backend by firing its own events, which seems to work well because both graphical interface and the backend are event driven | 17:31 |
| roadmr | cr3: hmm that might work, so we'd need to pass the manager thingy to the UI as well? | 17:32 |
| roadmr | salem_: so most of the work is done by the plugins: collecting information about the system, building the list of jobs to execute, ordering them and resolving dependencies | 17:33 |
| cr3 | roadmr: very astute, which is not somethign I'm very comfortable doing because it's such a high level object, but certainly feasible | 17:33 |
| roadmr | salem_: actually running the jobs depending on which plugin they specify to use | 17:34 |
| roadmr | salem_: and several plugins take care of building the final report and submitting that info to (potentially several) places | 17:34 |
| cr3 | roadmr: I might be more comfortable passing a callback method, which might seem more native to event driven systems | 17:34 |
| roadmr | cr3: oh that'd be nicer! | 17:34 |
| cr3 | roadmr: the callback would obviously point to the manager's fire method | 17:34 |
| salem_ | roadmr, hm, ok, but can this be triggered by the UI, instead of the backend? | 17:34 |
| cr3 | err, manager's reactor's fire method :) | 17:35 |
| roadmr | salem_: potentially with what cr3 is suggesting, which would require some changes to the UI methods | 17:35 |
| salem_ | roadmr, yes, would requires some work, but in the end I think the layout will be flexible enough to build a nice UI | 17:36 |
| roadmr | salem_: cr3 has a nice graph of how messages travel around checkbox, but we fear it may drive you insane :( | 17:36 |
| salem_ | roadmr, no problem, I am interested to see this graph | 17:37 |
| cr3 | salem_: these are the messages exchanged between checkbox plugins: http://people.canonical.com/~cr3/checkbox-message-graph.png | 17:37 |
| cr3 | salem_: you can identify where the user interface is being called because those messange handler methods are consistently prefixed with prompt_* | 17:38 |
| roadmr | argh, I don't see anything pyqt-related in main :( | 17:47 |
| salem_ | roadmr, python-qt4 ? | 17:47 |
| salem_ | apt-cache says it is in main | 17:48 |
| roadmr | salem_: I don't see it in Precise's manifest from the CD, but I may be doing something wrong :) | 17:48 |
| cr3 | roadmr: python-qt4 may or may not be on the CD which is probably not a huge deal for now, as long as we at least depend on packages from main: http://archive.ubuntu.com/ubuntu/pool/main/p/python-qt4/ | 17:50 |
| roadmr | cr3: ok cool :) | 17:50 |
| * roadmr apologizes heh | 17:51 | |
| cr3 | roadmr: I find the shipit use case of getting a cool ubuntu cd and trying it in a store far more likely than someone downloading and burning a kubuntu image to try it in a store | 17:51 |
| roadmr | oh yes, kubuntu | 17:52 |
| cr3 | roadmr: however, with friendly.ubuntu.com, I find it equally likely for someone on either ubuntu or kubuntu to want to try checkbox where instructions should be updated accordingly | 17:52 |
| roadmr | cr3: yep | 17:52 |
| cr3 | roadmr: hm, if you were looking at germinate for the ubuntu cd, it might be possible that python-qt4 is on the kubuntu cd which would just be a bonus :) | 17:53 |
| roadmr | cr3: I'm still unsure on what to do about the gstreamer dep on kubuntu, maybe some kubuntuer can tell us how it's done on their side | 17:53 |
| cr3 | roadmr: if the tests are optional, we can either have those tests require gstreamer or, if the tests are mandatory, we could consider rewriting them to have a lower level dependency like pulse | 17:54 |
| roadmr | cr3: they're mandatory, maybe we could have two sets of tests: ones depending on gstreamer and others depending on whatever kde uses | 17:55 |
| cr3 | roadmr: either way, I don't think it would be a huge undertaking | 17:55 |
| cr3 | roadmr: that would work too | 17:55 |
| roadmr | cr3: jedimike can surely frob things so that it considers either set of tests as valid | 17:55 |
| cr3 | roadmr: however, I was wondering what would happen if both requires are met; you'd get two sets of audio tests :) | 17:55 |
| roadmr | cr3: yep, so I'll stop worrying too much about it | 17:55 |
| roadmr | cr3: but that would require some wacko having gstreamer on kubuntu | 17:55 |
| cr3 | roadmr: if our assumptions can be broken, they will | 17:56 |
| roadmr | cr3: well it's ok, what would be baffling is if one set of tests passed *and* the other failed :) | 17:56 |
| cr3 | roadmr: that's when I wished we had electrocuting keyboards so, when someone answers tests inconsistently: zap! | 17:57 |
| brendand | cr3 - actually i've always thought about checkbox being able to specify more complicated logic for 'requires' | 17:59 |
| brendand | cr3 - errr, i mean depends | 17:59 |
| brendand | cr3 - such as 'wireless_after_suspend' depends: suspend_advanced or suspend_advanced_auto | 17:59 |
| brendand | cr3 - so audio_gstreamer could depends: not audio_pulseaudio :) | 18:00 |
| roadmr | that'd rock :) | 18:00 |
| brendand | and vice versa | 18:00 |
| cr3 | brendand: agreed, I've also seen use cases for depending on something to fail rather than implicitly something to pass | 18:01 |
| cr3 | brendand: oh wait, that's what you meant by "not audio_pulseaudio", nevermind :) | 18:01 |
| brendand | cr3 - well, depends means ran and passed right? | 18:02 |
| brendand | cr3 - or just ran? | 18:02 |
| cr3 | brendand: passed | 18:02 |
| brendand | cr3 - that's what i thought | 18:02 |
| brendand | cr3 - that would also be useful, but maybe harder to specify. | 18:02 |
| cr3 | brendand: the original motivation is the build a dependency tree which would spare the user from answering redundant questions, like to test the number of packets that can be transfered over the network when the network test failed in the first place | 18:03 |
| brendand | depends: suspend_advanced:fail | 18:03 |
| * brendand needs to become au fait with the depends code | 18:03 | |
| brendand | it's a little tricksy. didn't neimeyer write it? or am i thinking of something else? | 18:04 |
| cr3 | the distinction seems to be that where we used to want a dependency tree, we now seem to want a decision tree | 18:04 |
| roadmr | hmm | 18:04 |
| cr3 | brendand: sadly, I wrote the dependency code but I'd love to blame niemeyer for it :) | 18:05 |
| brendand | cr3 - hey, he's not on this channel - so feel free! | 18:05 |
| roadmr | heheheh | 18:06 |
| brendand | cr3 - do you reckon it would be a big change from how things work at the moment? | 18:06 |
| alourie | hello | 18:06 |
| cr3 | brendand: it would be a much needed rewrite, so I'd be receptive | 18:07 |
| * cr3 steps out for lunch | 18:07 | |
| alourie | what is this splash of users on QA list lately? Was there any event that I missed where QA was introduced?... | 18:07 |
| alourie | s/introduced/PR-ed/ | 18:07 |
| brendand | alourie - i only just joined ubuntu-qa (not sure why i wasn't on it before, considering that ubuntu QA is my job :P) | 18:08 |
| brendand | alourie - is it abnormal? | 18:08 |
| alourie | brendand: well | 18:08 |
| alourie | let me just say that I haven't seen "hello" letters for about a year? | 18:08 |
| brendand | gema - did we do anything to push the ubuntu-qa list recently? | 18:09 |
| alourie | and now there have been, how many? about 5 this week? | 18:09 |
| gema | brendand: we changed the format of the meeting and sent the minutes | 18:09 |
| gema | alourie: it is great, isn't it? we are taking off | 18:10 |
| gema | alourie: a lot of exciting work to do | 18:10 |
| alourie | gema: bring it on!! | 18:10 |
| salem_ | cr3, ok, so, for now I should ignore those mockups and implement just a qtinterface just like the gtk one, right? | 18:10 |
| gema | alourie: I am on it, I need three days to write it all down in an email! | 18:10 |
| alourie | sure | 18:12 |
| alourie | gema: maybe you should not put everything in one mail? split some? | 18:12 |
| gema | alourie: and I think we are going to have a QA community coordinator soon too, that will bring joy to the list | 18:12 |
| gema | alourie: maybe I will create a wiki and point to it from the mail, that makes more sense | 18:13 |
| alourie | gema: we know we're going to have one | 18:13 |
| gema | alourie: cool :) | 18:13 |
| alourie | yea, wiki would be better. But once again, not everything on one page | 18:13 |
| gema | alourie: ok, I will see how it comes along, I need one place to dump all the ideas and then we can flesh them out as required | 18:14 |
| alourie | yea, split to parts | 18:15 |
| === gema is now known as gema_afk | ||
| === salem_ is now known as _salem | ||
| cr3 | _salem: sorry for the delayed response, I stepped out for lunch. to answer your question: right, just ignore the mockups for now | 19:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
