== Meeting information == * #xubuntu-devel Meeting, 16 May at 10:01 — 11:23 UTC * Full logs at [[http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-05-16-10.01.log.html]] == Meeting summary == === Open action items === The discussion about "Open action items" started at 10:07. * ''ACTION:'' Team: When is systemd landing? * systemd is in repo and usable - with quirks * not all service files are there * no concrete idea of when it will be default * ''ACTION:'' elfy will link the systemd-related blueprints to xubuntu's blueprint to keep development on the radar * : menulibre 2.0.4 in unstable and utopic, will sru back into trusty next week * knome has a CSS update pending on IS/pleia2 * ''ACTION:'' bluesabre to follow up debian-sync of lightdm-gtk-greeter 1.8.5 to utopic, then SRU back to trusty * ''ACTION:'' bluesabre to SRU menulibre-2.0.4 back to trusty * features blueprint has links to systemd blueprints === Announcements === The discussion about "Announcements" started at 10:26. * 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 * knome handed ochosi over they keys to LP teams === Discussion === The discussion about "Discussion" started at 10:29. * '''Create a testing PPA common to -team''' (10:30) * ''ACTION:'' ochosi to investigate and set up trusty-staging and utopic-staging PPAs * A PPA specifically SRUs shall be discussed with micahg * '''Use Trello''' (10:46) * ''ACTION:'' elfy to set up a trello "master" board for -team and send an email about it to the mailinglist * the team will vote on the trello board after it has been set up * '''Mailinglist/s''' (10:58) * ''LINK:'' https://lists.ubuntu.com/archives/xubuntu-devel/2014-May/010193.html * knome sent a proposal for mailinglists to the mailinglist * ''Vote:'' Should we implement knome's proposal in our development mailinglist? (Carried) * ''ACTION:'' ochosi to send an email to the mailinglist to continue the voting on knome's mailinglist proposal * '''Planning for milestone images''' (11:08) * ''ACTION:'' elfy to send email to -team about planning for milestone images (e.g. shall we participate in alphas?) * '''Assistive tech testing''' (11:10) * ''LINK:'' http://packages.qa.ubuntu.com/qatracker/testcases/1574/info === Schedule next meeting === The discussion about "Schedule next meeting" started at 11:17. * ''ACTION:'' ochosi to send an email to the mailinglist about a proposal to do team meetings this cycle == Vote results == * [[http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-05-16-10.01.log.html#329 Should we implement knome's proposal in our development mailinglist?]] * Motion carried (For/Against/Abstained 6/0/0) * Voters knome, elfy, slickymasterWork, ochosi, jjfrv8, bluesabre == Action items, by person == * bluesabre * bluesabre to follow up debian-sync of lightdm-gtk-greeter 1.8.5 to utopic, then SRU back to trusty * bluesabre to SRU menulibre-2.0.4 back to trusty * elfy * elfy will link the systemd-related blueprints to xubuntu's blueprint to keep development on the radar * elfy to set up a trello "master" board for -team and send an email about it to the mailinglist * elfy to send email to -team about planning for milestone images (e.g. shall we participate in alphas?) * knome * ochosi to send an email to the mailinglist to continue the voting on knome's mailinglist proposal * ochosi * ochosi to investigate and set up trusty-staging and utopic-staging PPAs * ochosi to send an email to the mailinglist to continue the voting on knome's mailinglist proposal * ochosi to send an email to the mailinglist about a proposal to do team meetings this cycle == Done items == * (none) == People present (lines said) == * ochosi (203) * elfy (108) * knome (84) * bluesabre (28) * meetingology (23) * slickymasterWork (17) * Unit193 (6) * brainwash (4) * jjfrv8 (1) == Full Log == 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 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 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 * meetingology 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 * meetingology 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 * meetingology 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 * meetingology 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 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 10:41 #action ochosi to investigate and set up trusty-staging and utopic-staging PPAs 10:41 * meetingology 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:53 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 * meetingology 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:01 (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 * meetingology 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 * meetingology 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