/srv/irclogs.ubuntu.com/2011/12/01/#ubuntu-testing.txt

charlie-tcaAll of xubuntu is done. everything passes on hardware01:10
charlie-tcagood night.01:11
=== bladernr_ is now known as bladernr_afk
=== yofel_ is now known as yofel
brendandgema - do you reckon it would be good to have an 'introductory' email for people like besi, who 'announce' themselves on the list?13:22
gemabrendand: what do you mean?13:23
brendandgema - i could respond with a few suggestions for him, but it would be good to have a uniform response which we can improve upon13:23
brendandgema - something like:13:23
brendand* irc channels13:23
brendand* wiki resources13:23
brendand* current activities (e.g. if alpa testing is running atm)13:23
brendandjust a suggestion13:24
gemabrendand: 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 :D13:24
gemabrendand: I am relying on whoever jono hires to be the QA community coordinator to start putting those things together :D13:25
gemabrendand: looks really good, like a small starter's guide, thanks13:30
brendandgema - no problem. it would be good to keep it somewhere and update it with extra stuff13:32
brendandgema - as i recall from my Symbian days, mailman supports a 'introduction email'. who controls the ubuntu-qa list?13:32
gemabrendand: no idea13:33
brendandgema - i bet it's hggdh13:33
gemabrendand: we can ask him when he comes online13:33
brendandjibel - i know you're a very busy man at the moment, but do you have admin access to ubuntu-qa mailing list?13:34
jibelbrendand, yes why  ?13:41
brendandjibel - ^13:42
brendandjibel - i wanted to know if there's an 'introduction mail' option in the mailman interface13:43
* jibel looking13:43
jibelhggdh, can you help, I lost access again13:45
jibelbrendand, sorry I eat the password again, we'll have to wait for Sir Carlos13:51
hggdhbrendand, jibel: I have never seen an 'introduction email', or similar, in mailman13:54
hggdhjibel: just a sec, and I will get the passphrase13:54
jibelbrendand, gema mailman has an autoresponder feature but nothing powerful14:05
brendandjibel - ok then14:06
=== bladernr_afk is now known as bladernr_
brendandhas 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 hardware14:21
=== bladernr_ is now known as bladernr_afk
=== bladernr_afk is now known as bladernr_
cr3nerochiaro: welcome to #ubuntu-testing! :)16:49
nerochiarocr3: :)16:49
cr3salem_: you too, I didn't recognize your nick :)16:50
roadmrhey 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
nerochiarosalem_: ah, different nick on here :)16:52
nerochiarosalem_: you're tiagosh on canonical's servers16:52
cr3salem_: that's alright, roadmr did most of the talking so I'm not offended at all :)16:52
roadmrhehe no problem16:52
salem_nerochiaro, yes, this is an old nick from freenode. i think tiagosh is already taken here16:52
cr3roadmr: 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 course16:53
roadmrcr3: sure, I'm working on it right now :)16:53
cr3salem_: 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 again16:53
nerochiaroand keep everyone of us in the meeting in CC16:53
nerochiaroso 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 here16:56
salem_nerochiaro, ok, thanks16:57
roadmrnerochiaro, salem_ ok16:57
salem_I am taking a look at the mockups and check if it is doable with the current code layout16:59
roadmrsalem_: it's just a general idea, the mockups are based on ubuntu-one-client17:02
roadmrsalem_: 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 submissions17:03
cr3roadmr: does the backend support the concepts illustrated in the mockups yet?17:03
roadmrsalem_: 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 mockups17:03
roadmrcr3: there are some that aren't supported :( like the global progress indicator17:04
roadmrcr3: 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
cr3roadmr: 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
roadmrcr3: and some may need both backend and UI support (like the submission saving feature)17:05
roadmrsalem_: no problem: https://docs.google.com/a/canonical.com/document/d/1gr8NiC_d2E5kuh1NVCdwIXLnm3HQZiwrl3nbYDLSCSg/edit?authkey=CLC2698I&hl=en_US17:05
cr3roadmr: I don't think the UI interface supports setting properties either and it would be sad if each UI set properties its own way17:05
cr3roadmr: 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 layer17:06
roadmrcr3: ok so maybe we will have to extend the interface :(17:06
roadmrcr3: how does the current gtk interface handle e.g. setting the launchpad id?17:07
roadmrcr3: I guess I could go look at the code :)17:07
cr3roadmr: we will, but my concern is to avoid asking salem to implement features that are currently incomplete which makes development rather difficult17:07
roadmrcr3: well yep, you're right about that...17:07
cr3roadmr: 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
cr3err, would it be a reasonable...17:08
roadmrcr3: well it depends, if it'll take salem_ a month it may not be worth it, we could ask him I guess :)17:09
roadmrcr3: it could be useful for him to get acquainted with how to interface with checkbox17:09
cr3roadmr: 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 email17:10
cr3roadmr: in other words, it's a generic method for prompting the user for text, not specific to the launchpad email at all17:10
cr3roadmr: exactly, I think just getting at par would be a nice acquaintance step17:11
cr3salem_: have you had an opportunity to look at checkbox a bit, at checkbox_gtk/gtk_interface.py in particular?17:11
roadmrsalem_: 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 already17:12
salem_cr3, dummy, but seems to work17:12
roadmrsalem_: 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 element17:12
cr3salem_: awesome, would you mind pushing those, perhaps to lp:~tiagosh/checkbox/qt17:12
salem_cr3, implemented just the show_info() and seemed to work17:13
roadmryay, salem_  is the man!17:13
cr3salem_: 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
cr3salem_: once you implement all the show_* methods, the interface should be feature complete17: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
cr3salem_: 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 over17:16
salem_cr3, sure, I can push to a branch17:16
cr3salem_: for now, I think it would be safest to assume the backend is driving until we know for sure what will happen next17:16
cr3roadmr: ^^^ sound reasonable to you?17:16
roadmrcr3: sure17:17
cr3salem_: 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
cr3salem_: 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
cr3salem_: 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 experience17:19
roadmrcr3: 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 contract17: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
cr3roadmr: 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 anyways17:20
cr3salem_: 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.0417:21
skaetAlpha 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
cr3salem_: 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 future17:22
cr3salem_: unless we can find one UI to rule them all, the plan is to keep the other ones17:22
roadmrcr3: other than that, exposing the job store (for the progress bar), and some way of handling submission saving/renaming, and submitting an existing .xml17:22
cr3salem_: 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 idea17:23
cr3roadmr: those are likely to be implemented as methods *in addition to* the existing UI methods, which might result in minor changes17: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 accordingly17:24
cr3roadmr: 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 commands17:25
roadmrcr3: sure, if some feature needs interface changes I think it's ok17:25
cr3salem_: 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 accordingly17:25
cr3salem_: 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 frontend17: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
cr3salem_: the backend does a fair amount of work17:30
roadmrsalem_: most of the behavior is implemented through plugins that register methods to be fired on events17:30
cr3roadmr: 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 driven17:31
roadmrcr3: hmm that might work, so we'd need to pass the manager thingy to the UI as well?17:32
roadmrsalem_: 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 dependencies17:33
cr3roadmr: very astute, which is not somethign I'm very comfortable doing because it's such a high level object, but certainly feasible17:33
roadmrsalem_: actually running the jobs depending on which plugin they specify to use17:34
roadmrsalem_: and several plugins take care of building the final report and submitting that info to (potentially several) places17:34
cr3roadmr: I might be more comfortable passing a callback method, which might seem more native to event driven systems17:34
roadmrcr3: oh that'd be nicer!17:34
cr3roadmr: the callback would obviously point to the manager's fire method17:34
salem_roadmr, hm, ok, but can this be triggered by the UI, instead of the backend?17:34
cr3err, manager's reactor's fire method :)17:35
roadmrsalem_: potentially with what cr3 is suggesting, which would require some changes to the UI methods17:35
salem_roadmr, yes, would requires some work, but in the end I think the layout will be flexible enough to build a nice UI17:36
roadmrsalem_: 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 graph17:37
cr3salem_: these are the messages exchanged between checkbox plugins: http://people.canonical.com/~cr3/checkbox-message-graph.png17:37
cr3salem_: you can identify where the user interface is being called because those messange handler methods are consistently prefixed with prompt_*17:38
roadmrargh, I don't see anything pyqt-related in main :(17:47
salem_roadmr, python-qt4 ?17:47
salem_apt-cache says it is in main17:48
roadmrsalem_: I don't see it in Precise's manifest from the CD, but I may be doing something wrong :)17:48
cr3roadmr: 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
roadmrcr3: ok cool :)17:50
* roadmr apologizes heh17:51
cr3roadmr: 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 store17:51
roadmroh yes, kubuntu17:52
cr3roadmr: 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 accordingly17:52
roadmrcr3: yep17:52
cr3roadmr: 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
roadmrcr3: 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 side17:53
cr3roadmr: 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 pulse17:54
roadmrcr3: they're mandatory, maybe we could have two sets of tests: ones depending on gstreamer and others depending on whatever kde uses17:55
cr3roadmr: either way, I don't think it would be a huge undertaking17:55
cr3roadmr: that would work too17:55
roadmrcr3: jedimike can surely frob things so that it considers either set of tests as valid17:55
cr3roadmr: however, I was wondering what would happen if both requires are met; you'd get two sets of audio tests :)17:55
roadmrcr3: yep, so I'll stop worrying too much about it17:55
roadmrcr3: but that would require some wacko having gstreamer on kubuntu17:55
cr3roadmr: if our assumptions can be broken, they will17:56
roadmrcr3: well it's ok, what would be baffling is if one set of tests passed *and* the other failed :)17:56
cr3roadmr: that's when I wished we had electrocuting keyboards so, when someone answers tests inconsistently: zap!17:57
brendandcr3 - actually i've always thought about checkbox being able to specify more complicated logic for 'requires'17:59
brendandcr3 - errr, i mean depends17:59
brendandcr3 - such as 'wireless_after_suspend' depends: suspend_advanced or suspend_advanced_auto17:59
brendandcr3 - so audio_gstreamer could depends: not audio_pulseaudio :)18:00
roadmrthat'd rock :)18:00
brendandand vice versa18:00
cr3brendand: agreed, I've also seen use cases for depending on something to fail rather than implicitly something to pass18:01
cr3brendand: oh wait, that's what you meant by "not audio_pulseaudio", nevermind :)18:01
brendandcr3 - well, depends means ran and passed right?18:02
brendandcr3 - or just ran?18:02
cr3brendand: passed18:02
brendandcr3 - that's what i thought18:02
brendandcr3 - that would also be useful, but maybe harder to specify.18:02
cr3brendand: 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 place18:03
brendanddepends: suspend_advanced:fail18:03
* brendand needs to become au fait with the depends code18:03
brendandit's a little tricksy. didn't neimeyer write it? or am i thinking of something else?18:04
cr3the distinction seems to be that where we used to want a dependency tree, we now seem to want a decision tree18:04
roadmrhmm18:04
cr3brendand: sadly, I wrote the dependency code but I'd love to blame niemeyer for it :)18:05
brendandcr3 - hey, he's not on this channel - so feel free!18:05
roadmrheheheh18:06
brendandcr3 - do you reckon it would be a big change from how things work at the moment?18:06
alouriehello18:06
cr3brendand: it would be a much needed rewrite, so I'd be receptive18:07
* cr3 steps out for lunch18:07
alouriewhat is this splash of users on QA list lately? Was there any event that I missed where QA was introduced?...18:07
alouries/introduced/PR-ed/18:07
brendandalourie - 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
brendandalourie - is it abnormal?18:08
alouriebrendand: well18:08
alourielet me just say that I haven't seen "hello" letters for about a year?18:08
brendandgema - did we do anything to push the ubuntu-qa list recently?18:09
alourieand now there have been, how many? about 5 this week?18:09
gemabrendand: we changed the format of the meeting and sent the minutes18:09
gemaalourie: it is great, isn't it? we are taking off18:10
gemaalourie: a lot of exciting work to do18:10
alouriegema: 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
gemaalourie: I am on it, I need three days to write it all down in an email!18:10
alouriesure18:12
alouriegema: maybe you should not put everything in one mail? split some?18:12
gemaalourie: and I think we are going to have a QA community coordinator soon too, that will bring joy to the list18:12
gemaalourie: maybe I will create a wiki and point to it from the mail, that makes more sense18:13
alouriegema: we know we're going to have one18:13
gemaalourie: cool :)18:13
alourieyea, wiki would be better. But once again, not everything on one page18:13
gemaalourie: 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 required18:14
alourieyea, split to parts18: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 now19:38

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!