16:04 <kees> #startmeeting
16:04 <meetingology> 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 <meetingology> 
16:04 <meetingology> Available commands: action commands idea info link nick
16:04 <kees> #topic action review
16:05 <kees> #meetingtopic action review
16:05 <kees> uhm... wtf
16:05 <kees> [topic] hello bot
16:06 <kees> so, infinity is out, so I guess I'll skip his actions?
16:06 <mdeslaur> sure
16:06 <kees> "mdeslaur to look into flavour CVE tracking"
16:06 <mdeslaur> you can carry mine forward too, I haven't had time to work on that yet
16:06 <kees> done!
16:06 <kees> #topic unity 8 PPA
16:07 <bregma> this is regarding https://bugs.launchpad.net/unity8-desktop-session/+bug/1585362
16:07 <bregma> we require either formal TB approval or rejection
16:07 <slangasek> [LINK] https://bugs.launchpad.net/unity8-desktop-session/+bug/1585362
16:07 <slangasek> right
16:08 <slangasek> 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 <slangasek> so this kind of question has come up in various forms over time
16:08 <kees> uuhhh... adds a PPA to to sources by default? no. put in -proposed? I don't understand the problem?
16:09 <mdeslaur> 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 <mdeslaur> I don't think that's appropriate
16:09 <slangasek> 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 <bregma> 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 <kees> the language in this bug doesn't explain anything to me. is this for _testing_, or is this for _default_?
16:10 <kees> if it's for testing, why is the TB needed?
16:10 <mdeslaur> the issue is that installing that PPA is likely to break people's systems...
16:11 <slangasek> this is for opt-in to the unity8 stack, for end users
16:11 <slangasek> the current unity8 stack, in the ppa, which is not the same as the one in xenial
16:12 <bregma> 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 <slangasek> 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 <kees> 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 <slangasek> kees: they wanted auto-ppa enablement on package install
16:13 <kees> no.
16:13 <kees> :P
16:13 <kees> that's not how Ubuntu does things. :)
16:13 <mdeslaur> the approval is for the ppa to be automatically enabled with a xenial update of one of the unity 8 packages
16:13 <kees> if someone wants to test new unity8, they can run the ppa adding tool. it's a single command line... ?
16:14 <kees> it seems like if someone can't do that, they shouldn't be testing things that will break their system.
16:14 <mdeslaur> 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 <bregma> 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 <mdeslaur> for example, will the new network-manager in there break their kde or gnome desktop?
16:15 <slangasek> it's not really one commandline, because it's "apt-add-repository <magicstring>; confirm scary commandline prompt; apt-get update; apt-get dist-upgrade"
16:15 <kees> and if that's too scary, you want someone to test a system-breaking ppa that can't handle said scariness?
16:15 <slangasek> I personally find the apt-add-repository interface much less simple than I think it ought to be :)
16:16 <kees> how about adding "update and dist-upgrade" to the apt-add-repository script?
16:16 <slangasek> +1 from me on that, but I'm not sure if that addresses kgunn/bregma's issue
16:16 <mdeslaur> how about simply adding a "enable-unity8-ppa" tool that prints an appropriate warning?
16:17 <kees> mdeslaur: is that any better than apt-add-repository?
16:18 <mdeslaur> 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 <mdeslaur> bregma: what testing is performed in that PPA to make sure it doesn't break kde or gnome desktops?
16:19 <slangasek> should we discuss the reasons why the packages in question are in this extra ppa in the first place?
16:20 <bregma> 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 <slangasek> mdeslaur: the ppa is primarily the phone ppa; so the baseline testing for GNOME/KDE compatibility is 0
16:20 <bregma> we are working on MIR for these packages for 16.10, so this should not be a problem going forward
16:20 <mdeslaur> 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 <slangasek> 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 <slangasek> and might get pulled in if the ppa is enabled
16:21 <bregma> yes
16:21 <slangasek> bregma: sorry, I don't understand how the MIR changes things
16:21 <mdeslaur> bregma: how is a MIR going to fix the issue of rapid releases?
16:22 <bregma> 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 <slangasek> 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 <slangasek> the SRU process adds calendar time, and should not block the phone team from getting updates done
16:25 <bregma> agreed, and that's part of how I see convergence working
16:25 <slangasek> 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 <bregma> 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 <slangasek> 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 <mdeslaur> +1
16:27 <slangasek> 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 <bregma> well, 16.04 has already been released, so I would see that as being a technical challenge
16:29 <slangasek> 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 <bregma> slangasek, yes, it's possible although they would remain in universe of course
16:30 <slangasek> i.e. I don't see any difference, technically, between doing this now for 16.04 vs. doing this for 16.10
16:30 <bregma> we have just not considered doing that
16:30 <slangasek> ok
16:31 <slangasek> 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 <slangasek> 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 <slangasek> but it also obviously means more team for your work to prep and validate those SRUs - no shortcuts there
16:32 <slangasek> more team for your work? hello brain
16:32 <bregma> that work will need to be done for 16.10 and onward, it's a matter of accelerating the plan
16:33 <bregma> but given that adding the PPA could possibly break other desktops resulting in increased support workload, it's a worthwhile consideration
16:34 <bregma> 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 <slangasek> ok
16:34 <kees> alrighty. settled for now, it seems...
16:35 <slangasek> btw I do remember internal discussion earlier about having a separate ppa for just the converged stack, with different requirements for contents
16:35 <slangasek> 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 <mdeslaur> I would vote -1 on auto-enabling it, yes
16:36 <slangasek> ok
16:36 <slangasek> bregma: you have enough guidance then? :)
16:37 <slangasek> (should we have a formal vote on the auto-enable question, for the record?)
16:37 <bregma> one question:  would this be a "standing SRU" or separate SRUs required for each update?
16:38 <slangasek> 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 <slangasek> when it touches other packages in the archive, those would need to be more ad hoc
16:39 <bregma> OK
16:40 <bregma> I think I have enough guidance on this, then
16:40 <bregma> I would like a formal vote on the matter to take back to my masters
16:40 <kees> #topic mailing list
16:40 <kees> erf, vote on which piece?
16:41 <mdeslaur> auto-enabling of the PPA
16:41 <slangasek> 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 <kees> so, "should package installs be allowed to auto-enable third-party PPAs?" is that the right language?
16:42 <slangasek> maybe with fewer words
16:42 <kees> I don't like the inverted question, let's try this...
16:43 <kees> #vote grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install?
16:43 <meetingology> Please vote on: grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install?
16:43 <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)
16:43 <kees> -1
16:43 <meetingology> -1 received from kees
16:43 <mdeslaur> -1
16:43 <meetingology> -1 received from mdeslaur
16:43 <slangasek> -1
16:43 <meetingology> -1 received from slangasek
16:43 <kees> #endvote
16:43 <meetingology> Voting ended on: grant exception for auto-enabling of stable-phone-overlay ppa on unity8 package install?
16:43 <meetingology> Votes for:0 Votes against:3 Abstentions:0
16:43 <meetingology> Motion denied
16:44 <bregma> thank you for your time
16:44 <slangasek> bregma: thank you!
16:44 <kees> and, for the second part, there's not really a vote needed: the recommendation would be to work with the SRU team.
16:44 <slangasek> ok
16:45 <slangasek> mailing list? :)
16:45 <kees> right.
16:46 <kees> so, nothing new there (this topic was the only one I saw)
16:47 <kees> #topic bugs
16:47 <kees> nothing new
16:47 <kees> #topic aob
16:48 <kees> anything?
16:48 <slangasek> not here
16:48 <mdeslaur> nope
16:48 <kees> #topic chair selection
16:48 <kees> looks like mdeslaur with slangasek as backup?
16:48 <slangasek> or would it be infinity with mdeslaur backup?
16:49 <slangasek> (doesn't matter :)
16:49 <kees> hm, yeah
16:49 <kees> okay, infinity with mdeslaur
16:49 <mdeslaur> ack
16:51 <kees> okay, thanks everyone!
16:51 <kees> #endmeeting