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