15:04 <knome> #startmeeting Xubuntu community meeting
15:04 <meetingology> Meeting started Thu Aug 15 15:04:52 2013 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
15:04 <meetingology> 
15:04 <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
15:04 <micahg> knome: do we have images/testers?
15:05 <smartboyhw> micahg, I will test for you guys:)
15:05 <GridCube> :)
15:05 <micahg> knome: we're still oversized I think, I should fix that
15:05 <knome> micahg, yes, we'll have testers
15:05 <knome> micahg, but we also need the SRU uploaded
15:05 <skellat> micahg: And that SRU kinda needs to be done eventually
15:05 <knome> (it's the docs)
15:05 <micahg> knome: SRU won't be in 12.04.3
15:05 <knome> micahg, aha?
15:06 * smartboyhw thinks we should get the main topic back on track so the Mir team doesn't get confused:P
15:06 <knome> micahg, then i don't know why we're releasing.
15:06 <knome> #topic Items carried on
15:06 <micahg> knome: updated kernel?
15:06 <micahg> knome: let's discuss later
15:06 * knome shrugs
15:06 <tvoss_> smartboyhw, no worries, all good on this end :)
15:07 <knome> #action bluesabre to create a basic user-profile-image app
15:07 * meetingology bluesabre to create a basic user-profile-image app
15:07 <knome> #action team to write lightdm greeter testcase
15:07 * meetingology team to write lightdm greeter testcase
15:07 <knome> #nick team
15:07 <knome> #action skellat to prepare blog article discussing updating & upgrading for users and why it is okay to do so
15:07 * meetingology skellat to prepare blog article discussing updating & upgrading for users and why it is okay to do so
15:08 <knome> i think those are the open items
15:08 <knome> #topic Team updates
15:08 <knome> apart from Mir testing, what's up?
15:08 <knome> (please use #info)
15:09 <skellat> #info skellat prepared an SRU bug for the revised documentation for 12.04
15:09 <knome> micahg, can we discuss why we can't get that uploaded and in the SRU?
15:09 <GridCube> #info Desktop of the week will choose and propose the first desktop for tomorrow, we hope it gets its proper place in the main site and social networks
15:10 <micahg> knome: week before image release is too late for an SRU
15:10 <micahg> it takes 7 days to get through -proposed
15:10 <knome> micahg, it is a documentation update, and the bug has been ready for ages
15:10 <lderan> #info adding in the ability for the installation slideshow to automatically use the version number, and soon the version name
15:10 <micahg> knome: right, but needs to be uploaded
15:10 <skellat> #info Unit193 and GridCube both made waves in media relative to the experimental XMir image
15:10 <knome> micahg, sure. but there has been enough time to do that.
15:11 <micahg> knome: right, but as no one has done it, it doesn't go in
15:11 <smartboyhw> #info 12.04.3 is next week...
15:11 <micahg> we can have it in updates a week from Monday hopefully, i'll try to upload this weekend
15:12 <skellat> #info skellat will be presenting UbuCon at Ohio Linux Fest 2013 and intends to represent Xubuntu whilst there
15:12 <knome> micahg, is it a given that it takes a week, or can we make it happen faster by poking the right people?
15:13 <micahg> knome: it would need to be in already to get on the image
15:13 <knome> GridCube, we'll have to see how to incorporate the gallery to the website. selecting is fine this week, but can we postpone release to next week, say mon/tue?
15:13 <micahg> we lost track of the release schedule unfortunately, so we weren't ready
15:14 <GridCube> knome: ill inform the team then
15:14 <knome> GridCube, thanks
15:14 <micahg> if I would've remembered, i would've uploaded already
15:14 <knome> micahg, we didn't - we just didn't have uploaders handy. we need to do something for that
15:15 <knome> micahg, if i can sort the rest of the bureaucracy and social things out, can you upload today?
15:15 <GridCube> #action: GridCube to inform the desktop of the week team that the site will be ready next week, we should prepare a few options for the upcoming weeks
15:15 * meetingology : GridCube to inform the desktop of the week team that the site will be ready next week, we should prepare a few options for the upcoming weeks
15:15 <skellat> Requests were made to multiple SRU vanguards as per procedure
15:15 <micahg> knome: sure
15:15 <knome> micahg, thanks
15:15 <knome> #action knome to make sure the docs hit the 12.04.3 SRU
15:15 * meetingology knome to make sure the docs hit the 12.04.3 SRU
15:15 <micahg> skellat: SRU people can't do anything until it's uploaded
15:15 <knome> #action micahg to upload docs SRU
15:15 * meetingology micahg to upload docs SRU
15:15 <micahg> if someone would've just reminded me 12.04.3 is coming I would've done it
15:16 <knome> sure
15:16 <skellat> micahg: Acknowledged.
15:16 <micahg> I didn't realize we were up against a dealine
15:16 * smartboyhw has, but too late:P
15:16 <knome> yeah, ACK
15:16 <lderan> GridCube: when & how are we deciding on the desktop? a mini meeting at some point?
15:16 <knome> #topic Announcements
15:16 <knome> i had one but i forgot...
15:16 <smartboyhw> knome, :O
15:16 * knome shrugs
15:16 <knome> anybody else+
15:16 <knome> ?
15:17 <skellat> Anybody who has Xubuntu stuff they would like to have given away at Ohio Linux Fest...please let me know
15:17 <knome> skellat, when is that?
15:17 <skellat> September 13th will be UbuCon
15:17 <knome> skellat, and, you should probably ask pleia2 if she has any excess
15:17 <skellat> Understood
15:17 <knome> skellat, or if we could make unixstickers.com send you some
15:17 <skellat> Cool
15:18 <knome> (they usually share revenue, but since we can't take money, they'll send us free swag now and then)
15:18 <GridCube> lderan: probably trhough the mails
15:18 <skellat> Anybody who is within the team and is able to make it to UbuCon is more than welcome to join us.  UbuCon will be free to attend on the 13th of September.  There will be standing recognition at the start of the day for all Ubuntu Member folks in attendance.
15:19 <knome> nice
15:19 <knome> have fun there skellat :)
15:19 <GridCube> lderan: not all the people in the desktop of the week can joing irc at the same time
15:19 <lderan> GridCube: sounds good to me
15:19 <knome> lderan, GridCube, can we discuss this at the end of the meeting?
15:19 <GridCube> sure, sorry
15:20 <knome> #topic New and emerging items
15:20 <knome> #subtopic Mir: Feedback and discussion, roadmapping the last week before decisions
15:20 <knome> Unit193, skellat, people: floor's yours
15:20 <skellat> I have some relevant bugs to lay out for the purposes of today's discussion
15:20 <skellat> LP Bug #1102757
15:20 <ubottu> Launchpad bug 1102757 in Mir "System compositor children receive all input events" [High,In progress] https://launchpad.net/bugs/1102757
15:21 <skellat> LP Bug #1196239
15:21 <ubottu> Launchpad bug 1196239 in Mir "Cannot change display resolution" [Critical,Triaged] https://launchpad.net/bugs/1196239
15:21 <skellat> LP Bug #1195811
15:21 <ubottu> Launchpad bug 1195811 in linux (Ubuntu) "nouveau: Abnormally high FPS (no vsync) on natively mir testing demo-clients." [Undecided,In progress] https://launchpad.net/bugs/1195811
15:21 <skellat> LP Bug #1193222
15:21 <ubottu> Launchpad bug 1193222 in XMir "Screen never sleeps; missing power management" [Critical,Triaged] https://launchpad.net/bugs/1193222
15:21 <skellat> LP Bug #1109963
15:21 <ubottu> Launchpad bug 1109963 in Mir "Mir lacks a direct rendering ("bypass") mode" [Critical,In progress] https://launchpad.net/bugs/1109963
15:21 <skellat> LP Bug #1102760
15:21 <ubottu> Launchpad bug 1102760 in XMir "Multi-monitor support incomplete - can't show different images on each screen" [Critical,In progress] https://launchpad.net/bugs/1102760
15:22 * tvoss_ waits a little :)
15:22 <skellat> First off, I want to thank tvoss_ for joining us today.
15:22 <tvoss_> skellat, thanks for having me here :)
15:22 <GridCube> :) yes, thank you tvoss_
15:22 <skellat> The bugs mentioned above look like the most major ones we need to worry about.
15:22 <skellat> Our goal in considering XMir/Mir overall is to address whether or not this represents an overall regression.
15:23 <tvoss_> skellat, sure, want me to quickly walk through them and relate them to the team's roadmap/current work?
15:23 <skellat> Will XMir/Mir present an experience to the user that markedly differs from that in 13.04, 12.10, and 12.04.
15:23 <skellat> tvoss_: Hold on just a moment
15:23 <tvoss_> skellat, sure :)
15:24 <skellat> We also have a request made via Jono Bacon to hold off on making our decision as some code is expected to land on August 22nd to address multi-monitor support and composite bypass.
15:25 <skellat> Before we get too far along, I would hand over to tvoss_ to address the Mir crew's roadmap/current work.
15:25 <knome> very well :) tvoss_: welcome!
15:26 <skellat> tvoss_: The floor is yours
15:26 <tvoss_> skellat, thanks :) so first off: thanks for testing Mir, and for putting together the iso. For the bugs that skellat layed out here: multi-monitor and composite bypass are features that the team is actively working upon
15:27 <tvoss_> for composite bypass, that would be 1109963, for multi-monitor work 1102760 and 1196239
15:27 <jono> (btw, I created https://wiki.ubuntu.com/Mir/GPUTesting for tracking testing for different GPUs)
15:27 <knome> tvoss_, jono pointed out that the deadline for those is August 22, is this still the target?
15:27 <tvoss_> knome, yup, the team is committed to land those features by that date
15:28 <olli> knome, we target landing on 8/22
15:28 <olli> but reality might have us +/-1d
15:28 <tvoss_> olli, true, thanks
15:29 <knome> tvoss_, olli: if you could keep us informed on that, would be great; aug 22 is set as our decision date, and if everything else seems to work for us we might want to postpone that a *few* days (not a week)
15:29 <tvoss_> knome, sure, we will make sure you are up to date. I would think a post to your ml is okay?
15:30 <olli> knome, our goal is to have the features available (and backed by a larger call for testing) with enough time to Feature Freeze on 8/29
15:30 <jono> knome, we will definitely keep you informed
15:30 <knome> tvoss_, definitely. if you send me your email i can add it to auto-approved if you aren't subscribed (olli as well)
15:31 <skellat> A small preference would be to avoid having to make the decision during the UDS timeframe
15:31 <tvoss_> knome, thanks
15:32 <tvoss_> skellat, noted down
15:32 <olli> tvoss_, shall we talk about the list of bugs skellat posted earlier
15:32 <tvoss_> olli, yeah, just looking at them again, filtering out the multi-monitor and bypass bugs/features
15:33 <olli> fyi: we consider MultiMonitor and composite bypass as major feature deliveries, whereas missing dpms is a bug at this stage
15:33 <olli> using dpms as an example
15:34 <tvoss_> yeah, for #1102757: vt switching is working now with XMir from the archive and I *think* the bug is fixed, too. Will check with the team tomorrow and update the status
15:34 <jono> skellat, why not make the decision in the UDS timeframe? isn't that what UDS is for? :-)
15:35 <smartboyhw> jono, I think the problem is that Xubuntu needs to make the FF
15:35 <tvoss_> olli, skellat for the dpms bug: Mir is capable of switching off the screen, we need to wire that up to the X side of things
15:35 <smartboyhw> Which is on 29th
15:35 <smartboyhw> FF = Feature Freeze
15:35 <skellat> jono: I'll come to that in a moment but we need to let the folks from the Mir crew continue
15:35 <jono> smartboyhw, ahh I see, too close to FF
15:35 <jono> np
15:36 * GridCube wonders if canonical would'nt just disregard the problems with ff in this matter
15:36 <jono> agreed about making the decision earlier :-)
15:36 <skellat> GridCube, that would be jumping ahead to another question.  But since we've disposed of LP Bug #1102757 let us let the Mir crew continue.
15:36 <ubottu> Launchpad bug 1102757 in Mir "System compositor children receive all input events" [High,In progress] https://launchpad.net/bugs/1102757
15:36 <tvoss_> skellat, finally: https://bugs.launchpad.net/mir/+bug/1195811 is being worked upon, too. It turns out to be an issue in the kernel (as per the comment stream on the bug) and we are making progress on it
15:36 <ubottu> Launchpad bug 1195811 in linux (Ubuntu) "nouveau: Abnormally high FPS (no vsync) on natively mir testing demo-clients." [Undecided,In progress]
15:37 <skellat> tvoss_: For that we had bluesabre experience it in testing Wednesday night directly
15:38 <tvoss_> skellat, ah, with XMir?
15:38 <skellat> Yes
15:38 <skellat> Any coordination with the Kernel crew on resolving that issue?
15:38 <tvoss_> skellat, mlankhorst is looking into it, he is pretty familiar with the nouveau and kernel drm bits
15:39 <skellat> Okay
15:39 <texadactyl> tvoss, I'd like to see a Mir on/off switch in lightdm.conf so that folks choose whether to try Mir or go straight to X
15:39 <olli> texadactyl, that's in place
15:40 <tvoss_> texadactyl, yeah. so you can disable Mir bei either apt-get removing unity-system-compositor or by commenting out type=unity in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf
15:40 <smartboyhw> I think he wants a GUI one....
15:40 <tvoss_> texadactyl, that's what I use to do benchmarking for example
15:40 <texadactyl> dont need a gui
15:40 <smartboyhw> texadactyl, heh, say it earlier and I would've told you that:)
15:40 <texadactyl> Which parameter tag for lightdm.conf?
15:41 <GridCube> GUIs are always good
15:41 <texadactyl> Sure but a parameter is enough
15:42 <GridCube> yes
15:42 <smartboyhw> texadactyl, in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf
15:42 <smartboyhw> Comment out type=unity if you don't want Mir
15:42 <tvoss_> texadactyl, so are you happy with commenting out type=unity in /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf?
15:42 <texadactyl> I was hoping for a flag type of parameter in /etc/lightdm.conf
15:42 <texadactyl> but ok
15:43 <skellat> Okay, if we can come back to LP Bug #1196239...I was wondering if the Mir crew could explain that issue a little further if possible.
15:43 <ubottu> Launchpad bug 1196239 in Mir "Cannot change display resolution" [Critical,Triaged] https://launchpad.net/bugs/1196239
15:43 <GridCube> shouldnt it be type=mir?
15:43 <smartboyhw> GridCube, no:P
15:43 <GridCube> type=unity makes no much sense to me
15:43 <texadactyl> No, "unity" is correct
15:43 <tvoss_> skellat, looking again
15:43 <GridCube> its not unity we want to disable its mir...
15:43 <smartboyhw> GridCube, because XMir needs the Unity System Compositor to work
15:44 <smartboyhw> That's why...
15:44 <texadactyl> unity-system-compositor is the executable that does the detection of graphics card
15:44 <texadactyl> In my case, it gives up    )-:
15:44 <GridCube> then, it should be the whole of that
15:44 <tvoss_> GridCube, in that case: just apt-get remove unity-system-compositor
15:45 <texadactyl> But we want folks who are able to try it
15:45 <texadactyl> Blowing up is ok
15:45 <texadactyl> (:
15:45 <texadactyl> Its part of the experience, yes?
15:45 <skellat> Okay, I think that line of discussion needs to be parked for the moment.  We can come back to it but we need to handle this last bug issue.
15:45 <GridCube> well no, thats not either, if its a setting, like to test no mir, then i would think its "use-mir=false" or something like that, but again im not a programmer and you know more
15:46 <texadactyl> agreed, cube
15:46 <tvoss_> skellat, so for the resolution bug: as mentioned on the comment stream, that is part of multi-monitor work. Mir is taking over display detection and configuration in the system-compositor scenario
15:46 <texadactyl> put it in lightdm.conf
15:46 <skellat> tvoss_: Okay, so that is folded into the whole matter.
15:46 <tvoss_> skellat, right, and X's xrandr is wired up to Mir in the XMir scenario
15:47 <tvoss_> skellat, that wasn't the case when the bug was filed but will be enabled by multi-monitor support
15:47 <skellat> tvoss_: A tricky set of legacies developed over 25 years that have had to be untangled in a very short amount of time, then?
15:48 <skellat> Now, to get back to the question from jono about avoiding UDS for making a decision.
15:48 <tvoss_> skellat, yes, but xrandr is straightforward enough to be able to wire it up to mir and its client side api
15:49 <skellat> The main reason we need to avoid UDS is because UDS-1308 falls around Feature Freeze.  Due to the varying schedules of our team, it must be remembered that last UDS we de-coupled from it to have the "Three Nights of Xubuntu" outside the UDS schedule so we could get maximum participation.
15:50 <skellat> For a decision this major we want to ensure we have it done somewhat before Feature Freeze and so that our uploader developers are also able to fully chime in.
15:50 <skellat> They have complicated schedules and their participation is essential.
15:50 <skellat> There has already been mailing list discussion about how to handle announcing during the UDS time period whatever decision we make but nothing final has come of that yet.
15:51 <jono> skellat, as I said, I now understand your point
15:51 <jono> I forgot FF was the same few days as UDS
15:51 <jono> agreed in making a decision earlier
15:51 <knome> jono, generally, from my POV, it is really weird that vUDS is literally ending up on the day of FF
15:52 <jono> knome, well, UDS is designed to plan the next three months of work
15:52 <knome> this makes it prone for developers to announce new things that "need" to be in the release really close to the deadlines
15:52 <knome> sure. then why not schedule it after the FF, if it has no connection with that?
15:52 <knome> everybody is busy before FF anyway
15:52 <knome> just saying, for future considerations
15:52 <jono> knome, well, that issue is not an issue with UDS timing but with the devs ;-)
15:53 <knome> well, it is
15:53 <jono> devs should not be announcing things that have to be in with a day's notice :-)
15:53 <knome> no, but devs are the ones that are attending UDS
15:53 <micahg> devs shouldn't be wasting time with days of meetings before FF
15:53 <jono> knome, I guess I don't understand the problem with UDS timing here
15:53 <skellat> Okay
15:53 <knome> and if that's right before FF, it's bad scheduling
15:53 <jono> oh I see
15:53 <jono> so the issue is devs focusing on UDS and not release?
15:53 <micahg> right
15:53 <jono> gotcha
15:53 <jono> agreed
15:54 <jono> we will try to prevent that in future
15:54 <jono> fair point
15:54 <xequence> why not have a UDS right after release, as usual?
15:54 <knome> (and the other point is that we've seen late announcements before, and from my POV, vUDS days before FF sounds a bad idea regarding that)
15:54 <xequence> and the next one 3 months after that
15:54 <smartboyhw> +1
15:54 <jono> np
15:55 <knome> or, announcing features that *will* land before FF, but basically makes everybody fix and tweak a lot of things
15:55 <knome> jono, if you see where i'm coming from?
15:55 <jono> knome, yup
15:55 <skellat> Right now I want to thank the Mir crew representatives for joining us and for all the hard work they've put into the monumental task they're undertaking.  Before we go into any questions, the last question I want to be put to the Mir crew is whether or not the somewhat general Feature Freeze exception for Touch announced by Steve Langasek would also allow continuing effort to be put in indirectly to land further refinements to desktop display
15:55 <jono> I agree in making UDS after FF
15:55 <knome> jono, great, thanks.
15:56 <jono> knome, will check the release schedule more rigorously in future when picking dates :-)
15:56 <xequence> oct, jan, april, july (I suppose July is not a good month for UDS)
15:56 <knome> jono, great
15:56 <smartboyhw> jono, will that be in effect for this UDS?
15:56 <jono> smartboyhw, I am not changing the dates of the UDS in two weeks, no
15:56 <jono> but the following one we will assess the release schedule more closely
15:57 <knome> thanks olli and tvoss_!
15:57 <knome> (and jono)
15:57 <knome> if nobody has anything else regarding mir, let's move on
15:57 <jono> thanks, folks
15:57 <GridCube> :)
15:57 <tvoss_> knome and all, thanks for the invitation and thanks for your feedback :)
15:57 <olli> skellat, re FFe: we target to not use an FFe for Mir/Xmir
15:58 <skellat> olli: Excellent.
15:58 <olli> for features specifically
15:58 <skellat> Thank you for joining us gentlemen.
15:58 <knome> tvoss_, olli: no problem! if it fits your schedule, i'm sure people won't mind you being around next week at the same time and place
15:58 <olli> we acknowledge that by 8/29 there will probably be bugs lingering
15:58 <smartboyhw> olli, if it's just bugfixes you don't need an FFe anyway:P
15:58 <olli> which we hope to squash well before Final Freeze
15:58 <tvoss_> knome, yup, I will be around
15:59 <knome> tvoss_, cheers!
15:59 <knome> olli, if you PM me your email address, i can add it to auto-approve on our developer mailing list
15:59 <knome> #subtopic Proposal for more structured handling of Xubuntu bugs
15:59 <knome> skellat, want to postpone?
15:59 <olli> knome, thx, will be here
15:59 <knome> skellat, or want to go ahead?
15:59 <skellat> knome: Carry over
15:59 <knome> oki
15:59 <knome> #subtopic Inclusion of Xfce 4.11 components in Xubuntu 13.10
15:59 <knome> i'm quite tight on time, but...
16:00 <knome> i would think we should cherry-pick some components
16:00 <micahg> that needs input from mr_pouit and I don't see him around
16:00 <knome> Noskcaj has been packaging some already
16:00 <knome> i'll get ahold of mr_pouit
16:00 <knome> basically, what i'm thinking is:
16:01 <knome> xfce 4.12 won't be released before 13.10 FF
16:01 <knome> it's not clear if it's released before 14.04 FF
16:01 <knome> the 4.11 components have things that we've been preparing for some time already, and it would be quite sad to not have them in the LTS
16:01 <micahg> well, if it were just the first issue and not the second, I'd happily take them now
16:01 <knome> and since they are ready now, i don't see any reason not to include them now (also to have a larger testing base)
16:02 <micahg> it's the second that concerns me, so that why I'd rather have mr_pouit's input
16:02 <knome> not being ready for 14.04?
16:02 <micahg> yeah
16:02 <micahg> we have to worry about the LTS -> LTS upgrades both ways
16:02 <knome> i mean, i'd still want *some* 4.11 stuff in 14.04 anyway
16:03 <knome> to name a specific feature, i would like the display-dialog in 13.10
16:03 <knome> there's also a patch that allows gtk3 indicators work on a gtk2 panel
16:04 <knome> it's not clear if it's ever going to be included in xfce itself, but it's something we might want to consider, as ochosi said
16:04 <micahg> patches we can cherry pick if needed
16:04 <micahg> as for the feature stuff, if mr_pouit signs off, I'll do my best to get stuff in by FF
16:04 <knome> i *know* it brings a delta, and i *know* it's more maintaining, but realistically, it's something we want more than the xfce team needs
16:06 <knome> so, anyway...
16:06 <knome> #action knome to contact mr_pouit about including xfce 4.11 stuff in 13.10
16:06 * meetingology knome to contact mr_pouit about including xfce 4.11 stuff in 13.10
16:06 <micahg> well, GTK3 indicators on GTK2 panel would mean dropping a lot of the GTK 2 indicator stack, so that's a big win
16:07 <knome> definitely, and would mean we could lose some maintaining from that side
16:07 <micahg> and get the messages indicator back ;)
16:07 <knome> yup
16:08 <knome> let's discuss this throughout the week more
16:08 <knome> #subtopic Schedule next meeting
16:08 <knome> #info Next meeting is August 22, 15UTC.
16:08 <knome> #endmeeting