[00:01] anybody around? [00:01] brainwash: poke [00:02] bluesabre: sorry, already heading to bed [00:02] ooh! [00:03] quick, link to lid-close bug [00:03] https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1303736 [00:03] Launchpad bug 1303736 in xfce4-power-manager (Ubuntu) "Black screen after wakeup from suspending by closing the laptop lid" [High,Confirmed] [00:03] yay, thanks! [00:03] (just bookmark this page: https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-14-04-point-1 ) [00:04] finished with adjusting the patch, will upload the package in a few [00:04] sweet [00:04] did you test it? [00:04] not yet [00:04] okeydokey [00:04] again, issue doesn't affect me [00:04] this is extremely weird [00:04] i wonder how it can and cannot affect anyone with a laptop [00:04] it should be consistent [00:04] race condition most likely [00:05] the only thing i *can* imagine is that your computer is "too fast" [00:05] and older ones fail [00:05] brand new gaming laptop :) [00:05] yeah [00:06] i guess if this works for "most" ppl, we should SRU it [00:06] (as i said, some of the testers were obviously mistaken) [00:06] anyway, let's continue at the meeting [00:06] gotta hit the hay [00:07] seeya ochosi [00:07] seeya! [00:07] and thanks for the patch! [01:23] ochosi: patched xfpm and light-locker-settings pushed to xubuntu-dev ppa [04:41] bluesabre: There's some updates to be done to the xubuntu-artwork package, want to fix them? [05:20] ochosi: Oh, so are we having another version of xubuntu-community-artwork? [06:17] Unit193: depends, i personally don't want to invest the time for another call and the follow-up work, i have enough on my plate this cycle i guess... [06:17] so if somebody else from the team wants to take that on, we can do another version, otherwise we can just ship the same wallpapers again [06:18] (knome: i just said "wallpapers" ^ , in case you don't have that on your highlight-list ;)) [06:21] Fine by me, so we don't have them. [06:21] I week in the job - excuses already :p [06:22] heh [06:22] that's an excuse from my other job though (artwork-lead) [06:22] (the one i've been doing for a few years) [06:23] "I would, but :effort:" [06:23] running the new call wouldn't be hard, but there's a bit maintenance and follow-up work [06:23] hehe [06:24] elfy: bluesabre uploaded an improved version to the xubuntu-dev PPA (xfpm+ll), could you give that a spin? [06:24] i gotta run off until the meeting [06:25] ochosi: yep [06:25] thanks! [06:26] i hope it works so we can get this over with :) [06:29] bbl [07:00] ochosi bluesabre - upgraded to new xfpm/lls - still works for me === yofel_ is now known as yofel [08:29] ochosi: do we already know that light-locker-settings is not in sync with the .desktop files before hitting the apply button for the first time? [08:30] I remember reading about this here [08:30] would be bug 1306917 [08:30] bug 1306917 in light-locker-settings (Ubuntu) "light-locker: screen always automatically locked" [Undecided,Confirmed] https://launchpad.net/bugs/1306917 === qwebirc795810 is now known as slickymasterWork [09:03] ochosi, lets see if we really want that. [09:03] o.- [09:03] hey bluesabre [09:03] you still or already awake? [09:03] woke up just to be here, ochosi should feel loved [09:04] !team | Wake up! [09:04] Wake up!: bluesabre, elfy, GridCube, jjfrv8, knome, lderan, micahg, mr_pouit, Noskcaj, ochosi, pleia2, skellat, slickymaster, Unit193 [09:05] It's 5am, no. [09:05] hmm [09:05] yeah, still an hour to go ;) [09:05] lol [09:05] oh [09:05] damn clock [09:05] bluesabre, GO BACK TO BED ;) [09:05] !team | ~morning [09:05] ~morning: bluesabre, elfy, GridCube, jjfrv8, knome, lderan, micahg, mr_pouit, Noskcaj, ochosi, pleia2, skellat, slickymaster, Unit193 [09:05] DST is not my friend [09:05] bluesabre, don't poke Unit193 ;) [09:06] "Let sleeping dogs lie"? [09:17] bluesabre: did you want to ask me sth? [09:17] I did, but ochosi popped up and answered [09:18] ok [09:19] elfy: did you also test with xscreensaver? [09:20] brainwash: no - why would I? [09:21] brainwash: yes, that is something we also want to fix at some point [09:21] elfy: isn't it obvious? :) [09:22] not at all - we don't seed xscreensaver [09:22] elfy: for upgraders, i'd prefer if we don't break xscreensaver [09:22] but yeah, primary goal is fixing the situation for clean installs with light-locker [09:22] and many have returned to xscreensaver [09:22] then someone should say something [09:22] somewhere were people can find it easily ;) [09:22] ok, please do it then/now :) [09:23] brainwash: "many" of a vocal minority though. we don't know anything about the majority of xubuntu users... [09:23] elfy: yeah, as it's a secondary goal, i wanted this to be tested first with light-locker [09:23] in fact it should work fine with xscreensaver [09:23] it's the no.1 workaround mentioned by users [09:23] because those users can switch back to the old behavior [09:24] by flipping an xfconf switch in xfpm [09:24] brainwash: it's the no 1 workround mentioned by the noisy ones [09:25] and the silent ones will use it [09:25] the noisy ones want all sorts of things that they aren't going to get [09:25] well, if they remove the light-locker package, light-locker-settings should be removed as well [09:26] bluesabre: yeah, but the setting is a hidden one and if lls modified it, they have to change it back by hand [09:26] I see [09:26] the best thing would be if xscreensaver worked with that logind-suspend too [09:26] if it does, then we have no problem [09:26] gotcha [09:27] but since up to now we had xfpm handle that, i don't know whether it does work this way [09:27] frankly, this is all a bit messy and very very confusing [09:27] even for me... [09:27] every time i have to really focus in order not to forget how things should work exactly [09:27] i guess i should write a process diagram or something [09:27] I'm just trying to keep up [09:28] bluesabre: join the club ... [09:28] yeah, i'll start something, give me a minute (or two) [09:32] http://dpaste.com/3QJ3PF1/ [09:32] does this help^ ? [09:33] (another note: i don't know yet how things work with xscreensaver, but the save bet is to always go for option 2) as that is the "old behavior") [09:35] bluesabre: ^ [09:35] so, "lock on suspend" TRUE, "inhibit logind" FALSE [09:36] "lock on suspend" FALSE, "inhibit logind" TRUE? [09:37] yeah [09:38] there's a side-effect though, all the other events (power-button, suspend-button) will also be handled by logind in case 1) [09:38] gtk-inspector is built in with gnome 3.14, and can be activated with a key combo... we might want to block that combo in the greeter when the time comes http://blogs.gnome.org/mclasen/2014/05/15/introducing-gtkinspector/ [09:38] ok, I'll update the patch now. [09:39] ochosi: please no side effects :P [09:39] brainwash: you can always come up with a better patch ;) [09:39] that side effect already exists though, right? [09:40] no [09:40] in the old, more hacky patch it doesn't [09:40] I see [09:40] there only the lid-event is inhibited [09:40] or not inhibited [09:40] (to be more exact) [09:40] so shipping the hacky patch would be fine if it works with xscreensaver too [09:41] but how can you sru the patch if it breaks something which has been fixed previously? [09:41] because power buttons are minor in comparison to losing work [09:41] lid-close event [09:42] i'll test now with xscreensaver... [09:42] xfpm won't inhibit it anymore and run the action specified via the settings dialog [09:42] or? [09:42] this is really confusing [09:43] I'll quickly push the tweaked lls [09:44] so the user selects "do nothing on lid close", but the system will suspend due to logind being in command again [09:44] brainwash: yeah, so stop spreading confusion! :) [09:44] xD [09:44] ochosi: anything I need to do with xscreensavr - other than install it and purge ll/lls ? [09:44] just doing my job.. brainwashing people [09:44] hehe [09:44] yeah,i never thought of it that way ;) [09:45] elfy: install it and disable ll, that should suffice [09:45] brb (hopefully) [09:46] mmm [09:46] that just comes back to the desktop with no password [09:46] yeah, seems like it [09:47] that wfm - when people complain - we can tell them to install ll/lls as that's what we're using now :p [09:48] what about the normal Xfce session? [09:48] no idea brainwash - I use THAT as often as I suspend in real life ;) [09:50] ok, i'm trying with the less hacky patch now [09:50] bluesabre: i'll test now and control the settings by hand, just to be sure ;) [09:51] I mean we don't want fix and break something at the same time [09:51] yeah, that usually comes with issues [09:51] why is the normal Xfce session usually so messed up? [09:51] it is? [09:51] the xfce4 package does not depend on ll, but still uses xfpm [09:51] usually it messes with my panel layout, font rendering, and other things [09:51] ochosi: good, the package probably won't be live for a while [09:54] bluesabre: hmmm [09:55] either there's a problem in the package with the patch, or there's something wrong with the patch [09:55] g_object_set_property: object class 'XfpmXfconf' has no property named 'inhibit-logind' [09:56] disclaimer: so the xfpm package 1.2.0-3ubuntu5~trusty~ppa2 doesn't work [09:56] there might be something missing [09:57] the branch was ahead of the 1.2.0 release [09:57] but it confirms my suspicion [09:57] so the diff only applied to where it was at the time [09:57] that xscreensaver isn't listening to logind, but needs to be called specifically by xfpm/xfsession on suspend [09:58] so there might be something that is needed that was committed between 1.2.0 and that branch [09:59] I'll do some testing and figure out if something is missing [09:59] right [09:59] http://dpaste.com/3XQKDF1/ [10:00] meeting time :) [10:00] so this is how things are according to my findings and testing so far [10:00] yup [10:00] !team | meeting-time! [10:00] meeting-time!: bluesabre, elfy, GridCube, jjfrv8, knome, lderan, micahg, mr_pouit, Noskcaj, ochosi, pleia2, skellat, slickymaster, Unit193 [10:01] o/ [10:01] #startmeeting [10:01] Meeting started Fri May 16 10:01:10 2014 UTC. The chair is ochosi. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [10:01] Available commands: action commands idea info link nick [10:01] hi everyone, just to know for sure, who's around? [10:01] o/ [10:01] o/ [10:01] \o [10:01] o/ [10:02] ok, just a small disclaimer, i'm still learning all this bot-business ;) [10:03] let's start with what's left from last time and update those items [10:04] knome: you had quite a few action-items from last time, want me to name them all or just wanna update them now? [10:04] all are done [10:05] i also ran the call for technical lead, so i guess the only open issue left is systemd ETA === qwebirc704438 is now known as slickymasterWork [10:07] #topic Open action items [10:09] I hate driving the bot too ochosi ;) [10:09] #action Team: When is systemd landing? [10:09] ACTION: Team: When is systemd landing? [10:09] any news on that? [10:09] ochosi: Define "landing" [10:09] elfy: sorry, i should've prepared better [10:09] Unit193: well, i guess there are two interesting aspects [10:10] ochosi: now worries - just letting you know I'd not be doing any differently :) [10:10] s/no [10:10] 1) when will utopic have a functioning systemd stack that we can test/use [10:10] 2) will utopic already fully switch to systemd [10:10] 1 - now [10:10] elfy: please #info ;) [10:10] ochosi: 1. It's in repo and usable. 2. It's not without quirks. 3. Not all service files are there, a couple ubuntu things only have upstart jobs. 4. Might not be default this cycle. [10:11] meh, #info folks :) [10:11] :p [10:11] #info systemd is in repo and usable - with quirks [10:12] #info not all service files are there [10:12] I can name modemmanager and whoopsie. [10:12] #info no concrete idea of when it will be default [10:12] but how does this affect xubuntu-desktop? [10:13] i'm not entirely sure [10:13] from what i remember, upstart user-sessions can still be run [10:13] not sure what happens to e.g. the indicators [10:13] brainwash: wanna investigate that? [10:13] user sessions are still upstart. [10:13] isn't it too early? [10:13] (or: does someone else know) [10:14] brainwash: why would it be too early? [10:14] the full stack is there and usable [10:14] I mean the upstart user session [10:14] if it will stay or go [10:15] quote from pitti's blog "To clarify, there is nofixed date/plan/deadline when this will be done, in particular it might well last more than one release cycle. So we’ll “release” (i. e. switch to it as a default) when it’s read" [10:15] ok [10:15] that can obviously happen any cycle then [10:15] guess we need to follow the status of systemd in unity [10:15] There's two blueprints to follow on that. [10:15] seems so [10:16] we could link those to one of our blueprints [10:16] just to keep them on the radar [10:16] that makes sense [10:16] elfy: blueprint-master, wanna #action that? :) [10:17] if you like :) [10:17] There's info on trello. [10:17] Unit193: yep - thanks :) [10:17] #action elfy will link the systemd-related blueprints to xubuntu's blueprint to keep development on the radar [10:17] ACTION: elfy will link the systemd-related blueprints to xubuntu's blueprint to keep development on the radar [10:17] ochosi: which xubuntu blueprint :) [10:18] we're missing a dev one ? [10:18] elfy: wait, i thought *you* are the master of blueprints? ;) [10:18] oh no ;) [10:18] I just built them for you :p [10:18] hehe [10:19] i think we oughta link it to the features blueprint [10:19] there wasn't a separate development blueprint in the 14.04 cycle, iirc [10:19] ok :) [10:19] yea - just looked at 14.04 [10:19] righty, so let's wrap this part up [10:19] or are there any more things wrt systemd? [10:20] #Team updates [10:20] are there any team updates? [10:20] not from me [10:20] neither from me :) [10:20] neither from me [10:20] s/neither/nor/ [10:21] #info: menulibre 2.0.4 in unstable and utopic, will sru back into trusty next week [10:21] cool [10:21] fixes a bunch of knome's bugs [10:21] #info knome has a CSS update pending on IS/pleia2 [10:21] and the menu corruption [10:22] bluesabre: do you know whether our 1.8.5 greeter is synced to utopic already? (was in debian 9 days ago) [10:22] that is, my part is done [10:23] hm, doesn't seem like it is in utopic already [10:23] doesn't seem like it [10:23] I'll see whats holding it up [10:23] probably stuck in m-o-m [10:24] #action bluesabre to follow up debian-sync of lightdm-gtk-greeter 1.8.5 to utopic, then SRU back to trusty [10:24] ACTION: bluesabre to follow up debian-sync of lightdm-gtk-greeter 1.8.5 to utopic, then SRU back to trusty [10:24] any other team updates? [10:24] ochosi: you can mark my action item as done :p [10:25] elfy: i guess you can do that yourself :) thanks! [10:25] if only all action items would be done so quickly ;) [10:25] (i guess we just need to assign them all to elfy) [10:25] ok, carrying on [10:25] # action bluesabre to SRU menulibre-2.0.4 back to trusty [10:25] #action bluesabre to SRU menulibre-2.0.4 back to trusty [10:25] ACTION: bluesabre to SRU menulibre-2.0.4 back to trusty [10:26] ah, more items bluesabre? [10:26] just attaching to my #info from before [10:26] #info features blueprint has links to systemd blueprints [10:26] I'm done [10:26] ok, ty [10:26] #topic Announcements [10:27] #info ochosi ran a call for Xubuntu technical lead on the mailinglist, there'll be a vote on the nominees in approximately two weeks at a meeting [10:27] any other announcements or shall we start the discussions? [10:28] #info knome handed ochosi over they keys to LP teams [10:29] ok, anything else? [10:29] no that i can think of [10:29] not from here [10:29] nope [10:29] #topic Discussion [10:30] #subtopic Create a testing PPA common to -team [10:30] ftr, i should probably be under -dev [10:30] *it [10:30] we've already started using the xubuntu-dev PPA for testing [10:30] +1 on that knome [10:31] but i was wondering whether it would be helpful or too much if we had one PPA per release [10:31] especially now that -team has the other privileges right (no access to LP team admin) [10:31] e.g. trusty-staging (for stuff we want to SRU) [10:31] or utopic-staging (for stuff that we want to get uploaded) [10:31] one per purpose sounds good to me [10:31] elfy: ^ ? [10:31] logically that sounds right [10:31] it does makes sense [10:32] unless it's a lot of work [10:32] that ^^ [10:32] (it isn't) [10:32] bluesabre: what do you think? [10:32] I'm happy to go with the flow on this [10:32] we'll just need micahg to create the PPAs, then members of xubuntu-dev can push packages to it [10:32] knome: so one per purpose = xubuntu-staging (holding the bugfixes for all releases) [10:32] ochosi, probably better to do it per release/purpose [10:33] ochosi, as you already kind of proposed... [10:33] yup, just wanted to make sure [10:33] just one thought here [10:33] team members can also contribute packages and simon and I can sponsor them [10:33] bluesabre, i'd argue ~xubuntu-project-lead should own ~xubuntu-dev [10:33] we can also do an additional PPA with new applications we're considering to include [10:33] if we've got a trusty one I assume that stuff that's been dealt with will be removed once it's released properly? [10:33] (only if they aren't in the repos, obviously) [10:34] elfy: yeah [10:34] same goes for any other release [10:34] knome: that would be a good, sustainable idea [10:34] elfy, or just get obsolete (newer version number in archive) [10:34] if stuff to utopic has been uploaded, it'll be removed [10:34] ok [10:34] is "-staging" a clear enough suffix? [10:34] any other ideas? [10:35] for SRU's, it can be trusty-sru(-staging) [10:35] well, the question is will we really have so many packages that it justifies having a separate SRU PPA [10:35] as long as the name is communicated to the QA team, it's ok :P [10:35] wlel, [10:35] *well [10:36] trusty-proposed, utopic-proposed? [10:36] i think it would be a good idea to have that, because then person X could install trusty and the -sru PPA [10:36] (following in step with upstream) [10:36] and see if there are still high-impact bugs that need fixing [10:36] mixing -proposed there might be just confusing [10:36] bluesabre: I'd rather not give people any chance of accidentally enabling standard proposed [10:36] "i have the -proposed archive enabled" [10:36] "which?" [10:36] ah [10:37] fair points === qwebirc998502 is now known as slickymasterWork [10:37] mhm, i agree, proposed is probably confusing [10:37] we can also call it -bugfix [10:37] staging works for me [10:37] that's ambiguous ;) [10:37] either -staging or -sru or -sru-staging [10:37] but see my point for a separate SRU PPA [10:37] knome: +1 to that and the thinking [10:38] sure, i agree it *might* be useful, but that's mostly interesting for trusty [10:38] as it is LTS, we might want to SRU more to it [10:38] sure, we could have -sru PPAs for LTS releases only or so [10:39] ok, so let's create a trusty-staging, utopic-staging and trusty-SRU ppa? [10:39] yep [10:39] question [10:39] packages that have been tested from trusty-staging can be moved to trusty-SRU [10:39] bluesabre: shoot [10:39] ok [10:39] ...i'd probably make that trusty-sru-staging [10:39] that answered it [10:39] ok :) [10:39] though not every update is SRU [10:39] maybe trusty-updates? [10:40] updates is a used name as well [10:40] humm, again with the confusion :) [10:40] so yeah, using -staging everywhere is a good idea [10:40] ok, let's wrap this up, we have a few more things to discuss [10:41] knome: can i create those PPAs with my current LP rights or does micahg have to set them up? [10:41] i don't know [10:41] i never was involved with the -dev team [10:41] only admins can create PPAs [10:41] but again, i'd argue ~xubuntu-project-lead should own ~xubuntu-dev === qwebirc506388 is now known as slickymasterWork [10:41] #action ochosi to investigate and set up trusty-staging and utopic-staging PPAs [10:41] ACTION: ochosi to investigate and set up trusty-staging and utopic-staging PPAs [10:41] tech lead can be an admin [10:42] xpl necessarily doesn't need to be [10:42] let's discuss the -sru PPA again when it becomes necessary? [10:42] or shall we just create it as well for trusty only [10:42] yep [10:42] let's discuss it when we need it and when micah is around [10:42] ok [10:43] since he's the owner/admin [10:43] #info A PPA specifically SRUs shall be discussed with micahg [10:43] elfy: i guess next up we could either talk trello or ML proposal by knome, any preference from your side? [10:44] not from me [10:44] well - not much to say about trello tbh - it's all been said previously :) [10:45] elfy: ok, so the idea is to use trello *additionally* to blueprints? [10:45] for detail when it's necessary for other's to know that detail [10:45] ochosi, want to #topic? [10:46] #subtopic Use Trello [10:46] to me it looks like trello boards can be useful for subteams [10:46] eg. the qa team/people can cooperate via those [10:46] elfy: so we would link the trello pages in blueprints? [10:46] or how would that work [10:47] ochosi: I guess that would work [10:47] but if some do and some don't then it's pretty much a dead end [10:47] yeah [10:47] as you can see from this scenario, it might lead to a slightly increased administrational overhead if we use 2 systems :) [10:47] and if sub-teams do - there's not really any cohesiveness [10:48] but if the gain justifies it, it's ok [10:48] I'd say [10:48] if we do it then - we'd be better to have a 'team' board - at least then people can see the whole picture [10:49] subteams if they want to have a board of their own could link it in the team one [10:49] how would that differ from the status site? [10:49] what staus site? [10:49] won't we get a huge gigantic picture if we do one for team? [10:49] status.ubuntu.com [10:49] knome: that shows as much detail as the blueprint [10:50] elfy: yeah, i see your point on being able to add comments/detail [10:50] so you want a whole picture with all the details? [10:50] but the problem is, having that in one huge trello page will probably also be overwhelming [10:50] what do other members of the team think on this? slickymasterWork? bluesabre? [10:50] you know what - I haven't got the energy for this - just take it off the agenda [10:50] i know some teams have used the bluepring whiteboards previously [10:51] I really don't care anymore [10:51] it's not exactly trello though... [10:51] because no edit locks and stuff [10:51] I really felt that trello was a good asset to -qa during the T cycle [10:51] trello is handy, as long as the links are discoverable [10:52] suggestion: what if we set up a trello board for all the current blueprints items so we see how it would look in action? [10:52] at least I rely more on trello than on the -qa blueprint [10:52] ochosi, that's a good idea [10:52] i'm ok with trying this for one cycle and then evaluating it [10:53] so seeing whether administration has increased significantly and how ppl feel about using it [10:53] one thing is important though: i still want blueprints to be updated, because those *do* help, with bugreports linked etc they have features that trello doesn't have [10:53] elfy: would you be ok with this ^? [10:54] ochosi: the QA blueprint was kept up to date in the last cycle ;) [10:54] yes [10:54] sure, just saying that using trello would still mean we have to keep the other (slow, clunky) website up to date too ;) [10:55] you can't just eat the fresh sandwich and let the old one rot [10:55] it didn't really add much to my workload tbh - and the QA blueprint had probably more on it than any of the others [10:55] ok, great [10:55] ochosi, wait, are you upbringing us now? ;) [10:56] ochosi: well - I can set it up if you want - just want people to get an account if they've not got one [10:56] * knome eats the fresh sandwich [10:56] elfy: that'd be great. then send an email to the mailinglist about it? [10:56] i'd personally like to vote on it, if you're ok with this [10:57] ideally we could give ppl a chance to vote via the mailinglist too, this time [10:57] ochosi: that's fine with me of course [10:57] BUT [10:57] can we deal with the m/l and make it moderated first :p [10:57] hehe [10:57] well that's the next topic [10:57] :p [10:58] #action elfy to set up a trello "master" board for -team and send an email about it to the mailinglist [10:58] ACTION: elfy to set up a trello "master" board for -team and send an email about it to the mailinglist [10:58] after we decide to use it or not :) [10:58] #info the team will vote on the trello board after it has been set up [10:58] oh right [10:58] #subtopic Mailinglist/s [10:58] I thought you wanted to do that the other way round? [10:59] err, how? [10:59] first set it up, then let ppl test it [10:59] then vote, no?= [10:59] mmm [10:59] we can still let ppl vote on the mailinglist anyway, btw [10:59] would it not be better for us to vote first - and then do the work? [10:59] it was done already for the XPL election [10:59] I'm easy either way though :) [11:00] yeah, but not all of -team might've used trello before [11:00] i'd argue it's hard to take an informed vote unless you've seen how it'd turn out [11:00] ok - makes sense [11:00] i think it could be good for an informed decision to see it in action [11:00] ... [11:00] is it echoing in here? [11:00] but i understand it's work... [11:00] we don't have too many work items on blueprints yet [11:00] ok, let's get on the mailinglists [11:00] ochosi: yea - ok - I'll get it set up soon and then go from there [11:00] https://lists.ubuntu.com/archives/xubuntu-devel/2014-May/010193.html [11:00] (as we're already going overtime) [11:01] thanks elfy [11:01] overtime? who specified the meeting lasted for an hour? :P [11:01] bert [11:01] #info knome sent a proposal for mailinglists to the mailinglist [11:01] ;) [11:01] (i like the repetition there ;)) [11:01] ^ link above [11:01] knome: well, link it? [11:01] i did already [11:01] the bot picks it up that way? [11:02] yep [11:02] oh, great, wasn't sure [11:02] so, any thoughts on this proposal? [11:02] bluesabre, slickymasterWork, elfy ? [11:02] others? [11:02] i think it's the awesomest proposal ever [11:02] I'm happy with it [11:02] I'd not go as far as knome though :p [11:02] I strongly give a +1 on knome's proposal [11:02] I agree with it [11:03] yup, i'm also +1 on it [11:03] and I've got a +0.99 [11:03] on a more serious note, if it doesn't work, it's not a huge thing to revert [11:03] should we have a formal vote? [11:03] ochosi: I think so [11:03] we have no quorum [11:03] so it'd have to continue on the mailing list [11:03] yeah, so it's logged~ [11:03] and then take it to the list for team to vote [11:03] * elfy types slower ... [11:03] ok, let's start here and let the others vote on the ML [11:04] #vote Should we implement knome's proposal in our development mailinglist? [11:04] Please vote on: Should we implement knome's proposal in our development mailinglist? [11:04] Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) [11:04] +1 [11:04] +1 received from elfy [11:04] +1 [11:04] +1 received from ochosi [11:04] +1 [11:04] +1 received from slickymasterWork [11:04] +1 [11:04] +1 received from knome [11:04] +1 [11:04] +1 received from jjfrv8 [11:04] oh hey jjfrv8 :) didn't see you there [11:04] oooh a lurker :p [11:04] o hai jjfrv8 :) [11:04] bluesabre? [11:04] jjfrv8, o/ [11:04] +1 [11:04] +1 received from bluesabre [11:05] #endvote [11:05] Voting ended on: Should we implement knome's proposal in our development mailinglist? [11:05] Votes for:6 Votes against:0 Abstentions:0 [11:05] Motion carried [11:05] heh:) [11:05] lol [11:05] knome: so much for not having a quorum :p [11:05] well we don't [11:05] wait, how many are we? crap :) [11:05] we need two more [11:05] 14 [11:05] yep [11:05] where's Unit193? [11:05] ochosi: shame you can set votes required in here [11:05] fell asleep maybe... [11:06] lol [11:06] then it wouldn't have passed :) [11:06] #action ochosi to send an email to the mailinglist to continue the voting on knome's mailinglist proposal [11:06] ACTION: ochosi to send an email to the mailinglist to continue the voting on knome's mailinglist proposal [11:06] do we want to allow private voting? :P [11:06] perhaps that should be added to the bot in here - it's likely to happen everytime we vote on anything [11:06] nah [11:07] lderan!!! [11:07] (that was directed at knome, not elfy) [11:07] * knome gathered [11:07] ochosi: I guessed too :p [11:07] ok, we have two more discussion-topics [11:07] i have to run in 10-15mins though [11:07] just saying... [11:07] heh [11:07] btw [11:07] * slickymasterWork also [11:07] both mine - both quick [11:08] #votesrequired [11:08] Specifies the number of votes needed until the vote will pass. Example: #votesrequired 2 means you either need an aggregate of +2 or -2 to pass. [11:08] oh, :) [11:08] #subtopic Planning for milestone images [11:08] elfy: you got the floor [11:08] So - we need to make a decision on whether to go with Alpha's or not this cycle [11:08] or one of them [11:09] any pros/cons from your side? [11:09] I'd suggest I'll mail -team once we've got m/l moderated (or not) [11:09] that's ok [11:09] not really - I just need to know as early as possible [11:09] i'm fine with that [11:09] shall we just make it an action item and move on? [11:09] yep - wfm [11:10] #action elfy to send email to -team about planning for milestone images (e.g. shall we participate in alphas?) [11:10] ACTION: elfy to send email to -team about planning for milestone images (e.g. shall we participate in alphas?) [11:10] #subtopic Assistive tech testing [11:10] assistive tech is currently on the Settings Manager - I AM removing it from that test [11:11] the question is - do we need to actually test that or not - if not all I need do is remove it - if we do I'll need to build a test for it [11:11] what does/did the test do? [11:11] test the settings manager itself or the subdialogs? [11:11] gotta run, bbl [11:11] I spoke to Nick Skaggs - it seems that Ubuntu only test the install screen reader - no other tests done [11:12] bluesabre: ttyl! [11:12] ochosi: it tests sticky keys and the like [11:12] and mouse emulation [11:12] http://packages.qa.ubuntu.com/qatracker/testcases/1574/info [11:12] last section of that [11:13] right [11:13] it does need to be removed from Settings Manager - but whether we test it or not is the issue for me [11:13] frankly, i don't have a strong opinion on this [11:13] if there's something wriong with it - we'd not be fixing it [11:14] is that generally a rule for testcases, that we test stuff that we'd also fix [11:14] ? [11:14] not as such [11:14] * ochosi is a bit out of the loop with QA [11:14] i'd trust you as QA lead or others more involved in QA to discuss this and take an informed decision [11:14] we try to test things that we use - this is just a hang on in the wrong place [11:15] ok - well as I said I WILL be removing it - today :p [11:15] ok :) [11:15] I'm easy to build a new testcase if needed [11:15] sounds good to me [11:15] wanna #info or äaction that? [11:16] I'll talk more to Nick [11:16] ok [11:16] not really a need - I got the bug - and the MP waiting for me to send :) [11:16] ok [11:16] so we can move on? [11:16] yep - I'm good now thanks :) [11:16] ok, thanks elfy :) [11:17] #topic Schedule next meeting [11:17] as discussed previously, we could cycle meeting times this cycle [11:17] so the next meeting could be at a different time of the day [11:17] i'm still happy that this worked so well and so many of you showed up today [11:17] so thanks everyone! [11:17] ochosi: so how about this [11:18] cycle it through team leads - team name alphabetically [11:18] puts QA at the end :p [11:18] haha [11:18] meh, artwork, i need to do the first one ;) [11:18] that was your plan all along, right? [11:18] lol [11:18] we could cycle through team leads and the respective team lead [11:18] 1) decides on the meeting time [11:19] 2) chairs the meeting [11:19] lol, I'm hanging by a thread on the one after artwork [11:19] :p [11:19] that makes some sense - and people can call ad-hoc ones as is normal when needed [11:19] so i can do another meeting at a different time of the day [11:19] sounds like a good plan [11:20] question is whether next week is too early [11:20] I gotta run now, will be back after lunch [11:20] and XPL can call general meeting when he wants to [11:20] the 2 weeks rhythm worked fine in 14.04, no? [11:20] ochosi: appeared to [11:20] we had a one week interval at some point [11:20] and we'll have other avenues more useful - m/l without distraction [11:20] near the end at least [11:20] mhm [11:21] meh, i also wanted to discuss blueprints and ppl starting to fill them up [11:21] too late now [11:21] ochosi: m/l :D [11:21] #action ochosi to send an email to the mailinglist about a proposal to do team meetings this cycle [11:21] ACTION: ochosi to send an email to the mailinglist about a proposal to do team meetings this cycle [11:21] I assume you'll be doing what the last one did - talk to leads about blueprints [11:22] yeah, i'm considering to wait with that until the mailinglist is closed [11:22] blueprints are a dangerous mailinglist topic in terms of getting unasked responses [11:22] (à la: "please implement *this*, this is sooo important.") [11:23] i'll announce the next meeting time at some point then [11:23] need to check my calendar... [11:23] ok [11:23] guess that's it [11:23] #endmeeting [11:23] Meeting ended Fri May 16 11:23:41 2014 UTC. [11:23] Minutes: http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-05-16-10.01.moin.txt [11:23] thanks everyone! [11:23] thanks ochosi [11:24] ok, gotta go, have a nice day everyone! [11:24] cya ochosi [11:24] seeya elfy [11:26] meeting minutes are up [11:32] ty knome [11:46] knome: you got time to look at a MP? [11:48] or slickymasterWork [11:48] https://code.launchpad.net/~elfy/ubuntu-manual-tests/1319137/+merge/219822 [11:48] bbiab [12:28] elfy, on it [12:33] elfy: https://code.launchpad.net/~elfy/ubuntu-manual-tests/1319137/+merge/219822 [12:33] done [12:35] ty slickymasterWork :) [12:35] np elfy, my pleasure [12:36] :) [12:38] all synced now [12:38] * elfy wanders off again for a while [14:20] elfy, my Trello account name is @jjfrv8 === qwebirc603818 is now known as slickymasterWork [14:21] jjfrv8: added you - assume it's jjfrv8 :) [14:22] elfy, got it. Thanks. [14:22] :) [14:22] elfy: re: team board, currently it seems to only hold links to the blueprints, is that what it should be? [14:23] or is it simply not complete yet? [14:23] ochosi: yea, I'd say it was up to those in teams to do what they want with their lists - only way they'll know if it works for them [14:24] right, but how are you planning to handle the qa list then? [14:24] I'm not at all sure ... [14:25] :) [14:25] well you should set an example for others, otherwise how would they know how they can benefit? (assuming that some havent used trello before) [14:26] I might just add people to the QA one [14:27] if I add the QA lists to the team board it'll seem like a hostile takeover :p [14:31] heh, no it might actually look like it should, no? [14:32] ok - help for trello works \o/ [14:33] moved all the QA lists to the team board [14:35] ochosi: well sort of, depends how many lists sub-teams decide they need :) [14:36] humm, that's a bit what i was afraid of to be honest [14:36] that you cannot easily collapse these lists [14:36] so if we want "the full overview", it'll be huge [14:37] otherwise we might just end up with what knome mentioned earlier, boards per team === qwebirc693416 is now known as slickymasterWork [14:37] which was why I left QA seperate - so if someone needs to know something specific look there [14:38] mmm [14:38] let me think [14:38] right, i presumed there was a nice way to get this "full overview", i thought you mentioned that as something you'd want in the meeting, but i might misremember that [14:39] (the ideal solution would be a better, user-friendlier launchpad i guess) [14:39] that's probably a convergence of me not explaining and others thinking I meant something else :p [14:41] well at least it means that it makes sense to set trello up so others really understand what it means to use it :) [14:41] just playing on the QA one [14:41] now that it's empty :p [14:43] eheh === qwebirc207130 is now known as slickymasterWork === qwebirc808673 is now known as slickymasterWork [14:54] ochosi: played with that - ripped it apart - left some notes so people can see how filtering works [15:02] ochosi: reassign bug 1310264 to xubu default settings and apply the proposed workaround? [15:02] bug 1310264 in xfce4-whiskermenu-plugin (Ubuntu) "Can't search/find items in the Settings Manager" [Undecided,Confirmed] https://launchpad.net/bugs/1310264 [15:13] brainwash: i'm +1 on that as my comment suggests, i just have a few other things to do right now, can you take care of it? (link it to the utopic features blueprint and re-assign it to x-d-s) [15:13] oh, so no chance to get it in for trusty? [15:14] it's a bit tricky I guess [15:16] well even if we SRU it to trusty, it needs to go through utopic [15:16] so we should target that first anyhow [15:16] yes, but we could leave it assigned to the trusty blueprint, or? [15:17] changes will be carried on to utopic anyway [15:20] you can leave the bugreport linked to the 14.04.1 blueprint, but i'd want it to be assigned to utopic features too [15:21] ok [15:22] ty [15:22] bug 1024482 too? it's the missing busy cursor problem caused by the greeter [15:22] bug 1024482 in unity-greeter (Ubuntu) "Mouse cursor theme does not change from default after login" [Undecided,Confirmed] https://launchpad.net/bugs/1024482 [15:22] feature or bugfix? [15:23] give me a minute (or a few), haven't seen that one yet [15:23] the linked debian report explains the problem better [15:25] ok, will look at that [15:25] just gotta finish something else first... [15:26] sure [15:28] ali1234: is your mwm hints patch still needed for gtk 3.12? [15:29] maybe I'm just confused about what's going on [15:41] ochosi brainwash - I'm going to assume I had a glitch or something with parole, reinstalled since - cpu usage appears to be normal http://pastebin.com/dcGcxWTJ [15:42] elfy: same audio file? [15:43] brainwash: that's a few audio files [15:43] and it doesn't matter if it's the same file - it wasn't just one - and if you think I'd remember which out of 36k music files it was ... [15:44] ah ok [15:44] :) [15:45] sigh - bluesabre - that ping was supposed to be for you ^^ :) [15:45] sorry brainwash - I wondered what blue sabre was doing here this time of the day lol [15:47] :D [15:47] elfy: i told them before one of them should change nicks :D [15:47] ha ha ha [15:47] bluesabre did [15:48] maybe he forgot about it again [15:48] elopio thinks I should change mine - no chance :p [15:53] brainwash, you could just /nick brainwashed [15:53] I'm not brainwashing myself [15:54] or s/brainwash/brainwasher/ [15:55] maybe [15:55] but only for 1 day :) [17:25] brainwash: don't know/don't care [17:26] i have no interest in supporting gnome's poor design decisions [19:13] what is the package name of the app-menu indicator triggering #1181134? [19:13] https://bugs.launchpad.net/ubuntu/+source/xfce4-indicator-plugin/+bug/1181134 [19:13] Launchpad bug 1181134 in xfce4-indicator-plugin (Ubuntu) "xfce4-indicator-plugin crashed with SIGSEGV in g_type_check_instance_cast()" [High,Triaged]