== Meeting information == * #ubuntu-meeting-2: action review, 19 Jul at 16:04 — 16:51 UTC * Full logs at [[http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-07-19-16.04.log.html]] == Meeting summary == === action review === The discussion about "action review" started at 16:04. === hello bot === The discussion about "hello bot" started at 16:05. === unity 8 PPA === The discussion about "unity 8 PPA" started at 16:06. * ''LINK:'' https://bugs.launchpad.net/unity8-desktop-session/+bug/1585362 === mailing list === The discussion about "mailing list" started at 16:40. * ''Vote:'' grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install? (Denied) === bugs === The discussion about "bugs" started at 16:47. === aob === The discussion about "aob" started at 16:47. === chair selection === The discussion about "chair selection" started at 16:48. == Vote results == * [[http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-07-19-16.04.log.html#106 grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install?]] * Motion denied (For/Against/Abstained 0/3/0) * Voters mdeslaur, kees, slangasek == Done items == * (none) == People present (lines said) == * slangasek (46) * kees (42) * bregma (22) * mdeslaur (19) * meetingology (11) == Full Log == 16:04 #startmeeting 16:04 Meeting started Tue Jul 19 16:04:16 2016 UTC. The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 16:04 16:04 Available commands: action commands idea info link nick 16:04 #topic action review 16:05 #meetingtopic action review 16:05 uhm... wtf 16:05 [topic] hello bot 16:06 so, infinity is out, so I guess I'll skip his actions? 16:06 sure 16:06 "mdeslaur to look into flavour CVE tracking" 16:06 you can carry mine forward too, I haven't had time to work on that yet 16:06 done! 16:06 #topic unity 8 PPA 16:07 this is regarding https://bugs.launchpad.net/unity8-desktop-session/+bug/1585362 16:07 we require either formal TB approval or rejection 16:07 [LINK] https://bugs.launchpad.net/unity8-desktop-session/+bug/1585362 16:07 right 16:08 I would've liked to get the discussion on this one started on the mailing list, given that I'm not sure we'll finish in a live TB meeting, but ENOTIME :/ 16:08 so this kind of question has come up in various forms over time 16:08 uuhhh... adds a PPA to to sources by default? no. put in -proposed? I don't understand the problem? 16:09 The list of packages in the PPA is troubling, since it contains more than just unity 8 stuff, like a newer network-manager, etc. 16:09 I don't think that's appropriate 16:09 kees: the problem is that this is the ppa that contains the various packages which have been forked for the phone product and have not been SRUed into the release 16:09 the over all goal is to make it as simple and easy as possible for people to test the Unity 8 desktop on 16.04 without a two-step (and hence error-prone) process 16:10 the language in this bug doesn't explain anything to me. is this for _testing_, or is this for _default_? 16:10 if it's for testing, why is the TB needed? 16:10 the issue is that installing that PPA is likely to break people's systems... 16:11 this is for opt-in to the unity8 stack, for end users 16:11 the current unity8 stack, in the ppa, which is not the same as the one in xenial 16:12 it's definitely not for default 16.06, not for default 16.10 which should have all the required packages in main by then 16:12 because the phone team's process has very good CI to prevent regressions for their stack, but having to regression-test it in Ubuntu for all other use cases would slow down development to a molasses pace - so they generally haven't been SRUing 16:12 I still do not understand the problem: adding a PPA is already trivial for end users to do. what is the issue that needs TB approval? 16:13 kees: they wanted auto-ppa enablement on package install 16:13 no. 16:13 :P 16:13 that's not how Ubuntu does things. :) 16:13 the approval is for the ppa to be automatically enabled with a xenial update of one of the unity 8 packages 16:13 if someone wants to test new unity8, they can run the ppa adding tool. it's a single command line... ? 16:14 it seems like if someone can't do that, they shouldn't be testing things that will break their system. 16:14 I'm not sure the simple question that gets asked on that package upgrade is enough to inform users of what enabling that ppa entails 16:14 users, eben the technically inclined, have a history of clicking on shiny things without reading the documentation first, a one-click install is less error-prone 16:15 for example, will the new network-manager in there break their kde or gnome desktop? 16:15 it's not really one commandline, because it's "apt-add-repository ; confirm scary commandline prompt; apt-get update; apt-get dist-upgrade" 16:15 and if that's too scary, you want someone to test a system-breaking ppa that can't handle said scariness? 16:15 I personally find the apt-add-repository interface much less simple than I think it ought to be :) 16:16 how about adding "update and dist-upgrade" to the apt-add-repository script? 16:16 +1 from me on that, but I'm not sure if that addresses kgunn/bregma's issue 16:16 how about simply adding a "enable-unity8-ppa" tool that prints an appropriate warning? 16:17 mdeslaur: is that any better than apt-add-repository? 16:18 if the objection is that apt-add-repository is not discoverable and has scary messages, then a more specialized tool would fix that 16:18 bregma: what testing is performed in that PPA to make sure it doesn't break kde or gnome desktops? 16:19 should we discuss the reasons why the packages in question are in this extra ppa in the first place? 16:20 mdeslaur, at the moment there is mostly informal testing of the PPA on desktop, we're working on mringing that up to par 16:20 mdeslaur: the ppa is primarily the phone ppa; so the baseline testing for GNOME/KDE compatibility is 0 16:20 we are working on MIR for these packages for 16.10, so this should not be a problem going forward 16:20 right, so that would be my first objection...someone runs gnome, installs the unity 8 desktop to try it out, and it breaks their main gnome desktop 16:21 even if bregma's team made that part of their test plan for their updates, there are bound to be other updates landing there to fix phone issues that may not have been tested by them on the desktop 16:21 and might get pulled in if the ppa is enabled 16:21 yes 16:21 bregma: sorry, I don't understand how the MIR changes things 16:21 bregma: how is a MIR going to fix the issue of rapid releases? 16:22 they're going either have to branch their upstream projects like everyone else does so they can support Ubuntu as well as the phone 16:24 fwiw I have been of the view for some time (with my SRU team hat on) that I would like to see more of the packages that land in the overlay ppa SRUed into Ubuntu 16:24 the SRU process adds calendar time, and should not block the phone team from getting updates done 16:25 agreed, and that's part of how I see convergence working 16:25 but in general, since these packages also all exist in the main Ubuntu archive and are considered abandonware / not fit for purpose in those versions, I think ideally they would get SRUed and not just published to the overlay 16:26 our goal is to see Unity 8 in the ISO as an alternative session for 16.10 (hence the MIRs), which would require branching upstream so a rapid cadence contines in the PPA but changes get SRUd into the Ubuntu archives 16:26 however I know that getting SRUs done for each package is going to increase the load on the development team; so is that feasible at this stage? 16:26 +1 16:27 bregma: ok. so you're saying that's the roadmap for 16.10 forward, there would be landings in both the overlay ppa and as SRUs, but that's not on the roadmap for 16.04? 16:28 well, 16.04 has already been released, so I would see that as being a technical challenge 16:29 bregma: from my POV, it seems technically possible to start SRUing packages onto 16.04 today, forking off of the existing packages in the overlay and putting them through the SRU process 16:29 slangasek, yes, it's possible although they would remain in universe of course 16:30 i.e. I don't see any difference, technically, between doing this now for 16.04 vs. doing this for 16.10 16:30 we have just not considered doing that 16:30 ok 16:31 if you went that route, you wouldn't need the TB's blessing for anything; you'd be using the standard SRU process 16:31 and it means the updates would get verified to ensure they don't regress other stacks in Ubuntu, which is a nice assurance 16:32 but it also obviously means more team for your work to prep and validate those SRUs - no shortcuts there 16:32 more team for your work? hello brain 16:32 that work will need to be done for 16.10 and onward, it's a matter of accelerating the plan 16:33 but given that adding the PPA could possibly break other desktops resulting in increased support workload, it's a worthwhile consideration 16:34 I will take the suggestion back to the decision makers and defer the question of adding the PPA with the package install until that is resolved 16:34 ok 16:34 alrighty. settled for now, it seems... 16:35 btw I do remember internal discussion earlier about having a separate ppa for just the converged stack, with different requirements for contents 16:35 should I assume the consensus in the TB is that auto-enabling this on package install would also be unacceptable, regardless of the criteria for the ppa? 16:35 I would vote -1 on auto-enabling it, yes 16:36 ok 16:36 bregma: you have enough guidance then? :) 16:37 (should we have a formal vote on the auto-enable question, for the record?) 16:37 one question: would this be a "standing SRU" or separate SRUs required for each update? 16:38 bregma: for packages that Canonical is the upstream for within that stack, I would prefer we figure out a standing SRU policy for them that doesn't require writing per-update test cases 16:38 when it touches other packages in the archive, those would need to be more ad hoc 16:39 OK 16:40 I think I have enough guidance on this, then 16:40 I would like a formal vote on the matter to take back to my masters 16:40 #topic mailing list 16:40 erf, vote on which piece? 16:41 auto-enabling of the PPA 16:41 I'd posit [VOTE] decline to grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install; recommend convergence team work with SRU team to include their changes in the main Ubuntu archive" 16:42 so, "should package installs be allowed to auto-enable third-party PPAs?" is that the right language? 16:42 maybe with fewer words 16:42 I don't like the inverted question, let's try this... 16:43 #vote grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install? 16:43 Please vote on: grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install? 16:43 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) 16:43 -1 16:43 -1 received from kees 16:43 -1 16:43 -1 received from mdeslaur 16:43 -1 16:43 -1 received from slangasek 16:43 #endvote 16:43 Voting ended on: grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install? 16:43 Votes for:0 Votes against:3 Abstentions:0 16:43 Motion denied 16:44 thank you for your time 16:44 bregma: thank you! 16:44 and, for the second part, there's not really a vote needed: the recommendation would be to work with the SRU team. 16:44 ok 16:45 mailing list? :) 16:45 right. 16:46 so, nothing new there (this topic was the only one I saw) 16:47 #topic bugs 16:47 nothing new 16:47 #topic aob 16:48 anything? 16:48 not here 16:48 nope 16:48 #topic chair selection 16:48 looks like mdeslaur with slangasek as backup? 16:48 or would it be infinity with mdeslaur backup? 16:49 (doesn't matter :) 16:49 hm, yeah 16:49 okay, infinity with mdeslaur 16:49 ack 16:51 okay, thanks everyone! 16:51 #endmeeting Generated by MeetBot 0.1.5 (http://wiki.ubuntu.com/meetingology)