[16:00]  * slangasek waves
[16:00] <mdeslaur> \o
[16:01] <slangasek> wiki page says infinity or kees is chairing
[16:01] <slangasek> infinity is at a sprint right now so I'm not sure he'll make it
[16:02] <bregma> kgunn is at the same sprint (I believe) so I'll be substituting for him today
[16:03] <mdeslaur> hi bregma
[16:03] <kees> \o
[16:04] <kees> so I'm chairing?
[16:04] <mdeslaur> kees: congrats
[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> 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] <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> that's not how Ubuntu does things. :)
[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
[16:51] <meetingology> Meeting ended Tue Jul 19 16:51:05 2016 UTC.
[16:51] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-07-19-16.04.moin.txt
[16:51] <mdeslaur> thanks bregma!
[16:51] <mdeslaur> thanks everyone