18:59 <knome> #startmeeting Xubuntu community meeting
18:59 <meetingology> Meeting started Thu Jan 30 18:59:47 2014 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
18:59 <meetingology> 
18:59 <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
18:59 <knome> so who's here for the meeting
19:00 <jjfrv8-work> o/
19:00 <slickymaster> o/
19:00 <pleia2> o/
19:01 <elfy> yep
19:01 <knome> ok, cool
19:01 <knome> let me get my act together :d
19:01 <knome> !team | meeting time
19:01 <ubottu> meeting time: bluesabre, elfy, GridCube, jjfrv8, knome, lderan, micahg, mr_pouit, Noskcaj, ochosi, pleia2, skellat, slickymaster, Unit193
19:02 <knome> #topic Open action items from previous meeting
19:02 <knome> #action ali1234 follows up on gtk3 indicator status
19:02 * meetingology ali1234 follows up on gtk3 indicator status
19:02 <knome> #action elfy to poke Noskcaj if time-admin and users-admin do not exist in the next daily
19:02 * meetingology elfy to poke Noskcaj if time-admin and users-admin do not exist in the next daily
19:02 <knome> did that happen?
19:02 <ali1234> again already?
19:02 <ali1234> where does the time go?
19:02 <knome> ali1234, shoo :P
19:02 <elfy> poked and nothing happened
19:02 <knome> keeping it carried on to make sure things happen
19:03 <Noskcaj> o/
19:03 <knome> #action knome to be in touch with people re Tech Lead position
19:03 * meetingology knome to be in touch with people re Tech Lead position
19:03 <knome> still TBD
19:04 <knome> #action knome to send an email to the mailing list re: bluetooth
19:04 * meetingology knome to send an email to the mailing list re: bluetooth
19:04 <knome> TBD
19:04 <knome> #action ochosi to follow up on xfce 4.12 release with nick and report back
19:04 * meetingology ochosi to follow up on xfce 4.12 release with nick and report back
19:04 <knome> #action ~QA to write tests for new packages, sync to tracker and call for testing
19:04 * meetingology ~QA to write tests for new packages, sync to tracker and call for testing
19:04 <knome> elfy, want to carry that on?
19:04 <elfy> well it's ongoing
19:05 <knome> i ask you a simple yes/no question and you start with "well..." ;)
19:05 <elfy> well ...
19:05 <elfy> yes
19:05 <knome> do you need a weekly reminder?
19:05 <elfy> no
19:05 <knome> ok
19:05 <knome> haha, so dropping it then :P
19:05 <knome> #undo
19:05 <meetingology> Removing item from minutes: <MeetBot.items.Action object at 0x1769290>
19:05 <elfy> ok :p
19:05 <knome> #action team members that are able to test/use bluetooth stuff, consider which software they would like to use, if it matters
19:05 * meetingology team members that are able to test/use bluetooth stuff, consider which software they would like to use, if it matters
19:05 <knome> #nick team
19:05 <knome> that's it.
19:06 <knome> #topic Team updates
19:06 <knome> please use #info and #action (for new action items) as appropriate
19:06 <knome> lderan, autopilot
19:06 <knome> Unit193, -core email
19:06 <knome> #info knome updated the meetings page with the new structure
19:06 <slickymaster> #info slickymaster finished Mugshot's online documentation -> http://smdavis.us/doku/doku.php?id=mugshot-docs
19:07 <elfy> #info Image testing for the last 7 days -> 64 bit image tests 3, no 32 bit tests reported
19:07 <elfy> #info Upgrade testing since call earlier in the week - 64 bit 13.10 to 14.04 5 reported for update manager upgrading, no tests from image
19:07 <elfy> #info Upgrade testing since call earlier in the week - 64 bit lts to lts 5 reported for update manager upgrading, 3 reported for image update
19:07 <elfy> #info Upgrade testing since call earlier in the week - 32 bit 13.10 to 14.04 2 reported for update manager upgrading, no tests from image
19:07 <elfy> #info Upgrade testing since call earlier in the week - 32 bit lts to lts 2 reported for update manager upgrading, none reported for image update
19:07 <elfy> #info Settings Manager test call out soon - includes light-locker
19:07 <knome> #info knome looked into the docs SRU and the new, fixed package (thanks bluesabre) should land in precise any day.
19:07 <elfy> #info Manual testcase continues prior to calls
19:07 <knome> ali1234, news about gtk3 indicators?
19:08 <knome> #info knome, ochosi and pleia2 held a meeting and selected the winners for the community wallpapers
19:08 <ali1234> some changes were pushed to the indicators but still no fix to the core library problems afaik
19:08 <knome> #info knome did housecleaning on the blueprints
19:08 <knome> ali1234, ok, cheers
19:08 <Noskcaj> #info mugshot in debian NEW
19:08 <Noskcaj> #info menulibre updated
19:09 <Noskcaj> #info parole 0.6 in ubuntu repos
19:09 <knome> Noskcaj, i'd appreciate "#info Noskcaj did ..." (easier for the team reports)
19:09 <Noskcaj> ok.
19:09 <ali1234> it's looking a lot like we'll have to wait until feature freeze and then demand it's either fixed or rolled back
19:09 <slickymaster> #info slickymaster started to work on migrating Mugshot documentation into docbook format
19:09 <Noskcaj> #info Noskcaj updated gthumb to 3.3
19:09 <knome> ali1234, but new "features" are in already, just broken?
19:10 <micahg-work> ali1234, does the current gtk3 indicator stack need to be uploaded to the archive still or is that waiting on fixes?
19:10 <ali1234> micahg-work: there is nothing new on our side. the problems all exist in the unity stack
19:10 <Unit193> knome: Yes?
19:10 <ali1234> knome: the new features are in some packages and not others
19:10 <knome> Unit193, please #info that you actually did something!
19:11 <ali1234> that mismatch is half the problem
19:11 <knome> ali1234, okay. then we should get the new features in before FF if at all possible (there's still time)
19:11 <knome> ali1234, but other than that, FF shouldn't be the hard deadline for the fixes, and i'm optimistic of landing those fixes
19:11 <ali1234> i don't know the status of stuff like xfce4-panel actually
19:11 <micahg-work> I uploaded 2 SRUs, but I don't remember which ones
19:12 <ali1234> we can't land any fixes in libindicator3 for example, that is what is currently broken
19:12 <ali1234> and it is broken in unity too, still
19:12 <Unit193> #info Unit193 sent a message to the list about the xubuntu-core meta.
19:12 <micahg-work> ali1234, is there a summary of the issues somewhere (or list of bugs)
19:12 <knome> #info lderan made a list of apps that can be ran simple "does it open" tests with autopilot: http://paste.ubuntu.com/6840722/
19:13 <ali1234> micahg-work: see https://bugs.launchpad.net/indicator-network/+bug/1185565 and https://code.launchpad.net/~a-j-buxton/libindicator/remove-timeout/+merge/198070
19:13 <ubottu> Launchpad bug 1185565 in libindicator "Indicators should have Upstart jobs" [Medium,Confirmed]
19:13 <knome> ali1234, micahg-work: if you don't mind, i'll add an action item for you to follow up on it and actually fix the stupid issues
19:13 <knome> #action ali1234 and micahg to follow up on gtk3 indicator stack issues
19:13 * meetingology ali1234 and micahg to follow up on gtk3 indicator stack issues
19:13 <knome> #nick micahg
19:13 <ali1234> i already sent a MR, there's nothing more i can do until tedg gets around to fixing it
19:14 <micahg-work> ali1234, poke tedg and ask if he has time to review or can hand off to someone else
19:14 <ali1234> i'm poking him once a week already
19:14 <knome> micahg-work, any possibility you could oversee how that goes? would be good to have more people on top of the issue
19:15 <ali1234> i've spoken to him several times about this already and it's always "yeah, i'm working on it"
19:15 <ali1234> he knows and understands the problems we face
19:16 <micahg-work> well, that's great, but I don't see why an MR should go 8 weeks without a review
19:16 * micahg-work <-- pot
19:16 <ali1234> because it's part of a much bigger change, basically
19:17 <micahg-work> yes, but there are ways to move these things forward, maybe it should be merged into a branch instead
19:17 <ali1234> there are a bunch of other issues around this too, like under xubuntu it wont actually use upstart to launch indicators, because it's hardcoded to only do that in unity
19:17 <knome> looking at the bug, not everybody agrees with what is going on
19:17 <ali1234> knome: right
19:17 <ali1234> that's a problem too
19:18 <knome> i guess we're fine to do weekly reminders for a few more weeks
19:18 <knome> if things do not progress, look at it again then
19:18 <jjfrv8-work> sorry about that. I'm back.
19:18 <knome> i guess another thing you could try, ali1234, is add more reviewers for the MP.
19:18 <knome> jjfrv8-work, np :)
19:19 <micahg-work> rewriting the indicator stack for the LTS seems so wrong...
19:19 <ali1234> right, this is why i mentioned FF and either fix NOW or rollback
19:19 <micahg-work> yeah
19:20 <knome> as long as gtk3 indicators work for us, i don't mind how this falls
19:20 <ali1234> we can always add the workaround to the environment
19:20 <knome> ali1234, micahg-work: please obey the action item and follow up on it as much as needed :)
19:20 <knome> and i'm of course also available, if you need something i can do to help.
19:21 <brainwash> maybe we could already switch to gtk3 indicators and use the workaround (exporting an env var)
19:22 <micahg-work> wait, we're still on GTK2 indicators?
19:22 <knome> since FF is still somewhat far, i don't think it makes sense to push a workaround and then start using the new "real" fix
19:22 <ali1234> agreed
19:22 <ali1234> but it's always there if we need it
19:22 <brainwash> the workaround can be reverted easily
19:22 <knome> rather wait until the FF, and if the situation *then* looks stupid, do the workaround
19:22 <brainwash> ok
19:22 <knome> brainwash, it's still more work to get the workaround up than not.
19:22 <ali1234> micahg-work: i'm not sure what is actually in the archive, because i work mainly upstream
19:23 <micahg-work> ok
19:23 <knome> we have to believe things are going to be fixed eventually
19:23 <Noskcaj> micahg-work, i've got the stuff in a PPA, but i'd rather wait for a real release to upload stuff
19:23 <brainwash> yes, Noskcaj's PPA + workaround works fine
19:23 <Noskcaj> archive is all possible 4.11 stuff + garcon git snapshot
19:24 <micahg-work> while I generally prefer that, we need baketime for the LTS, now if it'll just be broken in the archive, there's no point in uploading
19:24 <ali1234> it's not as badly broken as gtk2 indicators...
19:24 <knome> well exactly, my opinion is: hold until nearer to FF
19:25 <knome> and see if things are fixed and then decide what to do, once, rather than uploading any workarounds now and having to poke around it later
19:26 <Noskcaj> Is that for both panel and indicator?
19:27 <brainwash> there is no panel 4.11 release yet
19:28 <knome> looks like we're done with this. people involved, please keep in touch with each other.
19:28 <knome> #topic Announcements
19:28 <knome> i have one!
19:28 <knome> at the end of the T cycle, jjfrv8-work will step from the doc lead position.
19:29 <knome> while the T cycle lasts, he will keep on leading, with the assistance of slickymaster
19:30 <knome> and if everything goes well, jjfrv8-work should be able to hand over the leader hat to slickymaster at the start of the U cycle
19:30 <knome> of course, with the approval of the team
19:30 * Unit193 approves.
19:30 * elfy approves
19:31 * pleia2 approves
19:31 <knome> we are going to have a meeting on docs issues sometime soon, where those two can update each other on the situation etc.
19:31 * Noskcaj approves  the approvals
19:31 <micahg-work> sure
19:31 <knome> (well the approval should happen later, when U cycle is starting :P)
19:31 <knome> so, anybody interested in docs... hear hear!
19:31 <knome> jjfrv8-work, slickymaster: you around to schedule?
19:31 <slickymaster> yeaps
19:31 <jjfrv8-work> yes
19:32 <knome> whatever time works for you two is the best
19:32 <knome> next week before/after the community meeting?
19:33 <jjfrv8-work> next week I should be pretty flexible
19:33 <slickymaster> next week is my ubuntu membership meeting
19:33 <slickymaster> it depends on how much it will eventually take
19:33 <knome> friday though, isn't that it
19:34 <slickymaster> on the UM meeting ins on the 6th
19:34 <slickymaster> is^^
19:34 <knome> aha
19:34 <knome> then i've mismarked that on my calendar ;)
19:34 <knome> what about wednesday 19utc then?
19:35 <jjfrv8-work> ok with me
19:35 <slickymaster> fine with me, also
19:35 <knome> ok, that's it
19:35 <knome> #info Documentation checkup meeting on Wednesday, Feb 5 at 19UTC
19:36 <knome> aaand thanks for both jjfrv8-work and slickymaster for all the work they have done this far and will do in the future!
19:36 <knome> any other announcements?
19:36 * pleia2 adds to calendar
19:36 <knome> pleia2, ta
19:36 <knome> pleia2, you can add thu 19utc as the community meeting while you're at it
19:37 <knome> ok, moving on
19:37 <knome> #topic Agenda
19:37 <knome> #subtopic Enabling more people to push to Xubuntu branches (separate branches team, or would -team do?)
19:37 <knome> micahg-work, ping
19:37 <micahg-work> yes?
19:37 <knome> see the subtopic
19:37 <knome> basically, we'd like to allow more people to be able to push to xubuntu branches
19:38 <micahg-work> depends on the branches
19:38 <knome> -default-settings
19:38 <knome> mostly, i think
19:38 <micahg-work> we can separate the branches from the uploaders team
19:38 <knome> mhm
19:39 <knome> do you think it would be ok to add them under ~xubuntu-team, or would you prefer a new team?
19:39 <Noskcaj> I'd suggest we allow -team to modify branches
19:39 <micahg-work> but I'd prefer to limit the people who can push to people who understand the package and have proven through MRs that they know what they're doing
19:39 <Unit193> Would be best to use merges and have a couple review and approve.
19:39 <micahg-work> yes
19:39 <knome> ok, so something like ~xubuntu-branches
19:39 * Unit193 likes to have at least bluesabre take a look.
19:40 <micahg-work> so, I'd basically move the xubuntu-dev team out of the DMB control and we would create a new team for uploaders when someone needs that
19:40 <micahg-work> xubuntu-dev is fine
19:40 <knome> ok,
19:40 <knome> when you say "when someone needs that", what are you exactly referring to?
19:40 <knome> when somebody gains packageset uploader access?
19:40 <micahg-work> yes
19:41 <Noskcaj> That takes for ever
19:41 <knome> right, i would hope that happens sometime soon
19:41 <knome> and rather create a new team for -branches
19:41 <Noskcaj> micahg-work, Is there anything you can do to speed up my application?
19:41 <Noskcaj> It will be a month tomorrow
19:41 <Noskcaj> probably a new record
19:41 <knome> but i guess i'm fine with doing what you proposed, then create ~xubuntu-dev-upload if/when we need it
19:41 <micahg-work> Noskcaj, it's being discussed
19:42 <Noskcaj> ok
19:42 <micahg-work> knome, the uploader team would be managed by the DMB, so, nothing to worry about there
19:42 <knome> micahg-work, sure
19:43 <knome> micahg-work, can i get back to you on this in a week or so, to land the change
19:43 <micahg-work> land what change?
19:43 <knome> the LP teams changes, and separating -dev from upload stuff
19:43 <knome> or would you rather just do it right away, or does it need some ack from the DMB?
19:43 <micahg-work> oh, I just need to discuss quickly with the DMB
19:44 <knome> ok, sure
19:44 <knome> #action micahg to talk with the DMB and separate -dev from upload rights so we can allow more people to push to xubuntu branches
19:44 * meetingology micahg to talk with the DMB and separate -dev from upload rights so we can allow more people to push to xubuntu branches
19:44 <knome> #info if we need packageset uploader rights for certain people later, we shall create a new team for that purpose
19:45 <micahg-work> nope
19:45 <micahg-work> DMB would create that
19:45 <knome> #undo
19:45 <meetingology> Removing item from minutes: <MeetBot.items.Info object at 0x1632310>
19:45 <knome> #info if we need packageset uploader rights for certain people later, we shall ask DMB to create a new team for that purpose
19:46 <knome> nitpicking says me!
19:46 <knome> #subtopic Status of Bluetooth in Xubuntu; what kind of testing we want to run, which software we want to use?
19:46 <knome> micahg-work, do you have any opinion to that discussion?
19:46 <micahg-work> ah, so, I think blueman upstream has be revived
19:47 <Noskcaj> fyi: i updated blueman last week
19:47 <knome> do we have a preference? do they all work with indicators, or do we need to consider that kind of issues?
19:48 <micahg-work> is there something better out there, IIRC, blueman was the only one that worked well that didn't pull in half the GNOME stack
19:49 <knome> then that sounds like a good one to use
19:49 <knome> if there's no problems with using that...
19:49 <micahg-work> if there's another alternative, I'm all ears, but with the recent resurgence of development on blueman, I think it's a good horse to be hitched to
19:49 <Noskcaj> I think blueman has a memory leak though
19:50 <cyphermox> there are no big alternatives really
19:50 <cyphermox> memleaks are fixable ;)
19:50 * micahg-work waves to cyphermox
19:50 * cyphermox waves back
19:51 <Noskcaj> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700863
19:51 <ubottu> Debian bug 700863 in blueman "blueman-applet eats up memory" [Important,Open]
19:51 <Noskcaj> There's two other memory leaks i know of in xubuntu, so if someone could help me with them after the meeting
19:52 <micahg-work> 1 year with no response from reporter , that bug isn't likely to be addressed
19:52 <Noskcaj> no
19:52 <knome> can anybody from the team even confirm that bug?
19:53 <Noskcaj> It's just blueman uses 40mb of ram here and i've never used bluetooth
19:53 <micahg-work> that doesn't sound like a memory leak as much as not loading on demand
19:53 <cyphermox> Noskcaj: guess it would be worth running it through massif
19:54 <micahg-work> if you said 400MB, that would sound like a memory leak
19:54 <Noskcaj> I'll leave it on during the day to see if i can reproduce it
19:54 <cyphermox> micahg-work: it really ought to be running all the time, to be able to get you anything
19:54 <cyphermox> unless you don't have a bluetooth device of course
19:54 <micahg-work> cyphermox, right, I have that on one machine, bluetooth is off and it's running
19:54 <cyphermox> ah
19:56 <knome> so i guess the gist is that we should use blueman.
19:56 <knome> great, go file bugs!
19:56 <knome> (:
19:57 <knome> #subtopic Discuss documentation translations
19:57 <knome> we should mostly do this on the docs meeting, but...
19:57 <elfy> ummm - so what about testing blueman - forget it ?
19:57 <knome> right... test it!  :)
19:57 <micahg-work> hrm?
19:58 <knome> micahg-work, hrm to what?
19:58 <micahg-work> can launchpad not translate the docs?
19:58 <micahg-work> hrm to test..
19:58 <knome> it can
19:58 <knome> we're doing that.
19:58 <knome> we have the .po files in the branch
19:58 <elfy> #action Someone with bluetooth to write a testcase
19:58 * meetingology Someone with bluetooth to write a testcase
19:59 <knome> but we need to tweak the packaging to build the translations and display them in a sane way
19:59 <knome> Unit193 has been helping with that
19:59 <slickymaster> there are already finish and portuguese versions of the docs
19:59 <slickymaster> finnish ^^
19:59 <knome> we also might need/want to set some kind of cut-off percentages, if that's not happening now
19:59 <knome> micahg-work, if you happen to know about that side as well, poke Unit193 and me..
20:00 <micahg-work> not too much, I could help on the packaging side
20:00 <Unit193> knome: It was for me, I have that set up but not sure if any sane person would like it. :P
20:00 <elfy> I've gtg - thanks - cya
20:00 <knome> micahg-work, that's probably helpful as well
20:00 <knome> but ok, let's follow up on that
20:00 <knome> #topic Schedule next meeting
20:01 <knome> #info Next meeting Thursday, Feb 6, 19UTC
20:01 <knome> #endmeeting