[15:01] <rbasak> o/
[15:01] <bdmurray> o/
[15:01] <cyphermox> o/
[15:01] <BenC> o/
[15:01] <cyphermox> do we have quorum? I'll chair instead of sil2100
[15:02] <cyphermox> looks like we do
[15:02] <cyphermox> #startmeeting DMB meeting
[15:02] <meetingology> Meeting started Mon Sep 26 15:02:08 2016 UTC.  The chair is cyphermox. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[15:02] <meetingology> Available commands: action commands idea info link nick
[15:02] <cyphermox> #topic Review of previous action items
[15:02] <cyphermox> sil2100 asked me to chair, since he was going to be on a uncertain connection
[15:02] <BenC> Has it reall been two weeks since the last meeting? My internal clock is misrepresenting terribly.
[15:03]  * rbasak is also on an uncertain connection
[15:03] <cyphermox> BenC: it has
[15:03] <BenC> And on that note, I must appologize for not updating the agenda.
[15:03] <cyphermox> no infinity here, but I'll poke him to do his PPU stuff for Gunnar.
[15:03] <rbasak> That's done actually.
[15:03] <cyphermox> oh
[15:03] <rbasak> slangasek took care of it for us.
[15:03] <cyphermox> good
[15:03] <cyphermox> what about the PPU acces for Otto?
[15:04] <rbasak> That I didn't have in my mind when I asked him, sorry.
[15:04] <cyphermox> ok, I will then
[15:04] <rbasak> If someone wants to prepare the edit-acl command for slangasek, I'm sure he'd be happy to oblige.
[15:04] <cyphermox> my tasks were done
[15:04] <cyphermox> yup
[15:04] <cyphermox> sil2100's tasks were done (libdumbnet and zerofree for ubuntu-cloud)
[15:05] <cyphermox> and finally mine (nacc to add to core-dev and annoucing results) are done too -- so looks like we just need to cover Otto's PPU now
[15:05] <cyphermox> I see no applications on the agenda...
[15:06] <cyphermox> BenC: was there anything that should be on today's agenda?
[15:06] <BenC> We pushed “Nicholas Skaggs and (Juju Delegated Team) (September 12th)” to this meeting.
[15:06] <cyphermox> balloons: are you around?
[15:07] <balloons> o/
[15:07] <balloons> Happy Monday to you all
[15:08] <cyphermox> #topic Juju Delegated Team
[15:08] <rbasak> o/
[15:08] <rbasak> I wasn't expecting to be available today, but I happen to be free and with a connection available right now.
[15:09] <cyphermox> ok!
[15:09] <cyphermox> well, we have an email thread describing the request for a Juju PPU team.
[15:10] <cyphermox> is everyone familiar with that thread or with last meeting's discussion so we can skip right to voting on the team creation? is there anything we need to discuss on that regard? (or was the voting done already?)
[15:11] <BenC> I’m good
[15:12] <bdmurray> I'm not caught up on the thread
[15:13] <cyphermox> rbasak had concerns with the complexity of the packages, and whether they shouldn't just require core-dev
[15:13] <cyphermox> the thing is, we should usually consider PPU uploader teams separate from who asked to have that access .. can we sufficiently well define the packageset?
[15:14] <rbasak> I believe that all the packages currently requested have the property that they are only dependencies of Juju and nothing else.
[15:14] <rbasak> So "Juju and supporting packages that aren't dependencies for anything other than Juju" or a more concise form of that maybe?
[15:16] <BenC> Yeah, let’s get the package set out of the way. I think that’s fairly well defined.
[15:16] <BenC> And uncontested, for the most part.
[15:17] <rbasak> If we were to decide that Juju can only be uploaded to by core devs, then there would be no point in having a packageset.
[15:18] <rbasak> I realise that it's a bit circular though. I don't mind which way round we do it.
[15:18] <rbasak> As you say, I think everyone agrees what the packageset should be.
[15:19] <cyphermox> well, I don't think it has to only be core developers. people can show interest in only juju and show that they can handle these special packages correctly without necessarily qualifying or willing to be core-dev
[15:19] <micahg> cyphermox: that's a point of contention
[15:19] <BenC> I agree. I think it’s actually more likely that some one would work on juju and not want or need core, than the other way around.
[15:20] <cyphermox> micahg: could you elaborate?
[15:20] <BenC> micahg: Is it contended because there’s an opinion that you need to be at the level of a core-dev to work on it correcly, or because you should be a core dev to do it?
[15:20] <micahg> https://lists.ubuntu.com/archives/devel-permissions/2016-September/000979.html
[15:22] <BenC> I agree, there needs to be a higher level of expertise for anyone working on juju, but I don’t agree that you should need core-dev permissions to do so.
[15:22] <cyphermox> uploads are uploads, we're not here to check if someone uploading is doing a bugfix or not
[15:23] <rbasak> What if we ask all DMB members here to express their opinion on my questions A-E in that email? Would that help? Are there any further distinctions or nuances in opinion that this would miss?
[15:23] <cyphermox> AFAIK we've worked the same way for other packages for which uploads have consequences -- that's why we look at the packageset and who requests access separately
[15:23] <micahg> I agree on that point, I'm still not sure about whether or not someone should be core-dev for juju, I'm leaning towards it's plumbing for package management, so people should have a decent understand of how things work
[15:24] <BenC> A) Yes, B) No
[15:25] <BenC> Given that, I move that we define juju as a package set and to allow PPU access to it on a case-by-case basis.
[15:27] <cyphermox> seems to be like "bugfix-only uploads for the PPU" is unenforceable, and arguably something that goes beyond the scope of the DMB
[15:28] <BenC> Yeah, and most of these points can easily bog us down to the point of hindering progress rather than enabling.
[15:28] <BenC> Which I think is our main goal.
[15:28] <cyphermox> perhaps we could vote on the packageset, then vote on rbasak's points and bring this up to the next TB meeting?
[15:28] <cyphermox> BenC: err, what? :)
[15:29] <BenC> We should be enabling progress and development rather than hindering it :)
[15:29] <cyphermox> oh, ok :)
[15:29] <BenC> Order of gramatical operations failure on my part.
[15:30] <rbasak> I think that given it's within the scope of the DMB to deny an application for PPU, it's also within the scope of the DMB to permit a limited PPU only. Whether or not we choose to do it, or whether or not it's a good idea, is a separate matter.
[15:30] <cyphermox> #vote for the creation of a juju packageset defined as "Juju and supporting packages that aren't dependencies for anything other than Juju"
[15:30] <meetingology> Please vote on: for the creation of a juju packageset defined as "Juju and supporting packages that aren't dependencies for anything other than Juju"
[15:30] <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)
[15:31] <rbasak> +1
[15:31] <meetingology> +1 received from rbasak
[15:31] <BenC> +1
[15:31] <meetingology> +1 received from BenC
[15:31] <bdmurray> +1
[15:31] <meetingology> +1 received from bdmurray
[15:31] <cyphermox> +1
[15:31] <meetingology> +1 received from cyphermox
[15:31] <micahg> +0
[15:31] <meetingology> +0 received from micahg
[15:32] <cyphermox> #endvote
[15:32] <meetingology> Voting ended on: for the creation of a juju packageset defined as "Juju and supporting packages that aren't dependencies for anything other than Juju"
[15:32] <meetingology> Votes for:4 Votes against:0 Abstentions:1
[15:32] <meetingology> Motion carried
[15:32] <rbasak> I'm not sure we need to send this to the TB, unless we're hung or really unsure or something. We can still decide to our best ability and allow balloons (or anyone else) to take it to the TB if unhappy still though.
[15:33] <cyphermox> rbasak: that's not what I meant though
[15:33] <rbasak> No?
[15:33] <cyphermox> I think we ought to proceed as usual to do the vote for the packageset, vote on the applicants, and then bring up this discussion on ubuntu-devel perhaps?
[15:33] <cyphermox> and if need be, have a decision made by the TB
[15:34] <cyphermox> even if juju is complicated, I don't think it qualifies as stuff that only core-devs should ever upload
[15:34] <cyphermox> I think very few such packages exist
[15:35] <cyphermox> even boot stuff typically has bad consequences if you do stuff wrong, but we can have very knowledgeable uploaders ready to do such uploads
[15:36] <cyphermox> #topic Nicholas Skaggs for juju packageset upload rights
[15:36] <rbasak> I have no objection to bring it up on ubuntu-devel if you would like to do that.
[15:36] <cyphermox> balloons: could you tell us more about what changed since last meeting?
[15:36]  * cyphermox kicks Launchpad, would be nice to see upload history right about now
[15:37] <balloons> cyphermox, you can at least still see http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=*&sponsor_search=name&sponsoree=*Skaggs*&sponsoree_search=name
[15:37] <balloons> but yea :-(
[15:37] <balloons> Anyways, I sent along an email about juju packaging history as I knew it, and my invovlement with it
[15:37] <micahg> yes, but boot loaders are very focused, yes, results can be disastrous, but there's specific knowledge involved, packaging plumbing would seemingly require knowledge of how other packages interact and can potentially interact with each other, which implies archive-wide understanding
[15:38] <balloons> There's also an on-going debate about 32-bit uploads, and work on getting an RC into the archive
[15:38] <cyphermox> micahg: juju doesn't affect the archive, only the system on which you run it
[15:38] <balloons> cyphermox, did you have anything specific you want an update on?
[15:39] <cyphermox> balloons: not necessarily, but I wasn't at the last meeting, so trying to catch up with approximate resources
[15:39] <balloons> here's my mail btw https://lists.ubuntu.com/archives/devel-permissions/2016-September/000965.html
[15:39] <BenC> balloons: I have a single question: How do you plan ro help resolve some of the packaging issues being raised?
[15:40] <BenC> Speficially, without vague things like “I’m going to make juju great again” :)
[15:40] <micahg> cyphermox: right, but isn't the idea to be a layer on top of the package manager to make it even easier to install groups of packages?
[15:40] <balloons> BenC, :-). Are you speaking about issues like the 32-bit issue?
[15:41] <cyphermox> micahg: following specific rules which aren't part of juju itself, and those recipes are reviewed differently, etc.
[15:41] <cyphermox> micahg: it's not very different from chef/puppet, etc.
[15:41] <BenC> Well, there seems to be a huge discussion on how best to move forward with juju packaging to satisfy some current problems. Things raised last DMB meeting.
[15:41] <cyphermox> ie. you're always free to destroy your computer, or your datacenter, if you so choose.
[15:41] <balloons> My goal in general has been to try and make juju a better upstream partner. I've sought to do that by addressing the various packaging issues raised before I started working on the package. This included things like breaking out dependencies and doing regular uploads
[15:42] <BenC> As juju PPU #1, how would you lead that movement?
[15:43] <BenC> balloons: Sorry to come across as pushy, but not past. What are your future plans?
[15:43] <balloons> I push for open discussions on hard issues and seek resolution. It's not ok to just stop doing things once they get hard.
[15:44] <balloons> My future plans are to beef up the autopkgtests a bit more, and make the juju ci packaging mirror what goes into the archive
[15:44] <balloons> I want to reduce the release timing for pushing something into a ppa to into the devel archive to nil
[15:46] <micahg> balloons: not to open up a can of worms, but is there a reason that juju isn't part of the CI train?
[15:46] <cjwatson> wut
[15:46] <cjwatson> most packages aren't
[15:47] <micahg> even the canonical developed ones
[15:47] <balloons> micahg, the CI train for phone images?
[15:47] <balloons> if so, the answer is simply that it doesn't ship on those images
[15:47] <micahg> for the archive
[15:47] <cjwatson> right, bileto (formerly called the CI train) mainly focuses on the code used on the phone; it's certainly possible to use it for other things, but might well be an impedance mismatch in a lot of cases, and is in no way a requirement
[15:47] <cyphermox> the CI train isn't meant just for phone images though
[15:48] <rbasak> Juju does have autopkgtests, assuming they're still there. I wrote a couple.
[15:48] <cjwatson> and in particular most server packages don't use bileto
[15:48] <cyphermox> otoh, cjwatson is right, and we shouldn't use it as a crutch to make it easier to do uploads
[15:48] <balloons> rbasak, absolutely, and they are still there. Specifically, I'm going to try and stamp out archive issues with LXD, cloud-init, or snaps breaking us (or vice versa)
[15:48] <micahg> it was one potential solution to the "we want point releases quickly"
[15:49] <balloons> as an aside, who does the manual qa on a silo if it's not going on the phone?
[15:50] <cyphermox> you, or some other person designated for these uploads.
[15:50] <sil2100> o/ Sorry for being late, on mobile but around
[15:50] <balloons> micahg, my solution for that has been to integrate autopkgtesting into our CI, along with running things like lint, and checking for copyrights, etc
[15:50] <sil2100> The QA process is only for vivid and phone stuff, so other series just get released as is
[15:51] <balloons> cyphermox, ahh interesting. So I do an upload, get a silo, then I do the signoff?
[15:51] <sil2100> Bileto, in this regard, can be used for any package anywhere - if, of course, it fits the project needs
[15:51] <cyphermox> we're drifting away from the subject though, should we go on to vote?
[15:52] <sil2100> Since as cjwatson mentioned, bileto might 'get in the way' if you dont have autopkgtest or follow some specific release process
[15:52] <sil2100> Yeah, sorry about that
[15:54] <cyphermox> #vote for Nicholas Skaggs to get uploads rights for the juju packageset
[15:54] <meetingology> Please vote on: for Nicholas Skaggs to get uploads rights for the juju packageset
[15:54] <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)
[15:54] <balloons> so rbasak, when I say "beef up autopkgtests", I mean adding tests to ensure uploads to lxd, cloud-init, snap-confine don't break our juju packaging or vice versa. We've struggled with catching LXD breakages before they hit the archive
[15:55] <rbasak> balloons: that wasn't my question :-)
[15:56] <rbasak> -1 for reasons I explained at https://lists.ubuntu.com/archives/devel-permissions/2016-September/000979.html
[15:56] <meetingology> -1 for reasons I explained at https://lists.ubuntu.com/archives/devel-permissions/2016-September/000979.html received from rbasak
[15:57] <cyphermox> +0, I see some uploads, but I can't look at a few, and I would prefer to see more uploads of other packages that will be on the package set.
[15:57] <meetingology> +0, I see some uploads, but I can't look at a few, and I would prefer to see more uploads of other packages that will be on the package set. received from cyphermox
[15:58] <BenC> +0
[15:58] <meetingology> +0 received from BenC
[15:58] <sil2100> +0
[15:58] <meetingology> +0 received from sil2100
[15:59] <micahg> -1  I agree with most of what rbasak said
[15:59] <meetingology> -1  I agree with most of what rbasak said received from micahg
[15:59] <BenC> I trust baloons capability, but I think the first person on juju PPU needs more of a leadership role than a technical one.
[16:00] <cyphermox> #endvote
[16:00] <meetingology> Voting ended on: for Nicholas Skaggs to get uploads rights for the juju packageset
[16:00] <meetingology> Votes for:0 Votes against:2 Abstentions:3
[16:00] <meetingology> Motion denied
[16:01] <balloons> Thanks for your consideration all. On rbasak's comments, as I told him, I do hope to see some wider discussion as I think he brought up some interesting points around packages and ppu permissions
[16:01] <sil2100> I think we all would prefer you to do a few more uploads through sponsoring for now, and certainly re-try in a bit
[16:01] <BenC> Agreed on that.
[16:02] <balloons> yea, my uploads for things like mongodb never showed up in the miner
[16:02] <balloons> I can work to make sure my name gets attached to things more; it'll happen naturally anyway
[16:02] <rbasak> It's OK if they don't show up on the sponsorship miner - just point to them in your (re-)application and explain your involvement.
[16:02] <rbasak> (with an endorsement from the uploader also describing/confirming your involvement, etc)
[16:03] <cyphermox> #topic Any other business
[16:03] <bdmurray> Is there a bug in the sponsorship miner then?
[16:04] <balloons> bdmurray, seems unlikely. More likely is that my sponser uploaded and it has there name (probably very few if any of these). And for the other things, it likely carries someone else who I colloborated with as the uploader
[16:07] <cyphermox> so, no AOB
[16:07] <sil2100> Not from me
[16:08] <cyphermox> but I did forget to write down the ACTION for creating the packageset.. who wants to do it?
[16:08] <sil2100> I could try
[16:08] <sil2100> The juju packageset, right?
[16:08] <cyphermox> yes
[16:08] <rbasak> Is there any point doing it now?
[16:09] <sil2100> I would get on it when Im back or tomorrow then if that's needed
[16:09] <cyphermox> well, you don't have to DO it, just own the action so that we eventually have it done
[16:09] <rbasak> I suppose it would make it easy to add someone to when it's ready.
[16:09] <cyphermox> rbasak: not now, but let's not forget.
[16:09] <cyphermox> ACTION: sil2100 to deal with the juju packageset creation
[16:09] <cyphermox> #endmeeting
[16:09] <meetingology> Meeting ended Mon Sep 26 16:09:44 2016 UTC.
[16:09] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-09-26-15.02.moin.txt
[16:09] <rbasak> The person who gets the future action to add someone to the packageset won't forget :-)
[16:09] <cyphermox> hehe
[16:09] <rbasak> But sure, do it now if desired, because it's a TB action so will take longer.
[16:10] <rbasak> Then adding will be quick in future.
[16:10] <sil2100> Thanks cyphermox for chairing!
[16:10] <cyphermox> sil2100: you're up next ;)
[16:10] <rbasak> Thanks all!
[16:10] <sil2100> Ill take the next meeting in this case ;)
[16:10] <sil2100> Yeah ;)
[16:31] <tyhicks> hello
[16:31] <mdeslaur> \o
[16:31] <tyhicks> #startmeeting
[16:31] <meetingology> Meeting started Mon Sep 26 16:31:30 2016 UTC.  The chair is tyhicks. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:31] <meetingology> Available commands: action commands idea info link nick
[16:31] <tyhicks> The meeting agenda can be found at:
[16:31] <tyhicks> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:31] <tyhicks> [TOPIC] Announcements
[16:31] <tyhicks> Otto Kekäläinen (otto) provided updates for trusty and xenial for mariadb (LP: #1605493)
[16:31] <tyhicks> Thank you for your assistance in keeping Ubuntu users secure! :)
[16:31] <tyhicks> [TOPIC] Weekly stand-up report
[16:31] <tyhicks> jdstrand: you're up
[16:32] <jdstrand> hey
[16:32] <jdstrand> last week I focused a lot on the docker interface, ancillary interface/backend reviews and getting the docker snap to work on classic. The interface is merged and I syncd with stakeholders to get an updated docker in the store.
[16:32] <jdstrand> Also did a lot of PR reviews, updated the dbus-app interface and discussed the unity8 interface with ted
[16:33] <jdstrand> snap-declaration assertions in the review tools and other review tools updates
[16:33] <jdstrand> iterate on the dbus-app interface (hopefully, waiting for PR feedback)
[16:33] <jdstrand> PR reviews, especially wrt /run/media and udisks2
[16:33] <jdstrand> continue to investigate what a 'network-namespace' interface might look like
[16:33] <jdstrand> few more policy updates and policy bugs to look at
[16:33] <jdstrand> snap-declaration assertions in the review tools and other review tools updates
[16:33] <jdstrand> oh, I repeated one of those. it's that important :)
[16:33] <jdstrand> that's it from me
[16:33] <jdstrand> mdeslaur: you're up
[16:33] <mdeslaur> I'm on triage this week
[16:33] <mdeslaur> I'm currently working on an embargoed issue
[16:33] <mdeslaur> and I have samba and clamav updates ready for testing
[16:34] <mdeslaur> that's about it, sbeattie, you're up
[16:34] <sbeattie> I'm in the happy place this week
[16:34] <sbeattie> I made progress on some apparmor reviews last week, and will finish those up
[16:34] <sbeattie> I have kernel signoffs to get through today
[16:35] <sbeattie> I'll try to pick up an update from the list as well
[16:35] <sbeattie> that's it for me, tyhicks?
[16:36] <tyhicks> I'm in the happy place this week
[16:36] <tyhicks> I'm trying to do SRU verification (LP: #1580463) (LP: #1614215)
[16:36] <tyhicks> jdstrand: it looks like im-config was removed from xenial-proposed :/
[16:36] <tyhicks> jdstrand: could you re-upload and I'll handle the SRU verification?
[16:37] <tyhicks> after that, I'll be back on trying to bring AppArmor UNIX domain socket mediation back to 14.04 + hardware enablement kernel
[16:37] <tyhicks> I hit a blocker last week and I'm now taking a different approach
[16:37] <tyhicks> I have some packaging changes to make today so that we continue to ship the 14.04 policy in the backported 16.04 package
[16:37] <tyhicks> then I'll be testing
[16:37] <tyhicks> jjohansen: you're up
[16:38] <tyhicks> sbeattie: either you or I need to look at bug #1627304 this week
[16:39] <sbeattie> tyhicks: okay
[16:39] <tyhicks> sbeattie: I can get to it mid-week and will let you know if/when I start working on it
[16:39] <tyhicks> I think jj isn't around just yet
[16:39] <tyhicks> sarnold: are you here?
[16:40] <tyhicks> chrisccoulson: go ahead
[16:40] <chrisccoulson> I've got a minor Oxide update to do this week. There aren't any planned Mozilla updates
[16:41] <chrisccoulson> I've got a few Oxide code reviews to get through too
[16:41] <chrisccoulson> Also, Firefox and Thunderbird fail to build on various architectures in yakkety, so I need to spend some time on that
[16:41] <chrisccoulson> Other than that, I'll be working through Oxide bugs as usual
[16:42] <tyhicks> thanks chrisccoulson
[16:42] <tyhicks> ratliff: you're up
[16:42] <ratliff> I'm on bug triage this week
[16:42] <ratliff> I'm finalizing the pillow update
[16:43] <ratliff> Design doc review and other internal tasks to complete
[16:43] <ratliff> back to you, tyhicks
[16:44] <tyhicks> thanks!
[16:44] <tyhicks> [TOPIC] Highlighted packages
[16:44] <tyhicks> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[16:44] <tyhicks> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[16:44] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/k4dirstat.html
[16:44] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/iscsitarget.html
[16:44] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/zeroinstall-injector.html
[16:44] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/w3af.html
[16:44] <tyhicks> [TOPIC] Miscellaneous and Questions
[16:44] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/minizip.html
[16:44] <tyhicks> Does anyone have any other questions or items to discuss?
[16:45] <sarnold> hey, sorry I'm late
[16:46] <sarnold> MIRs this week, not sure which ones to start next
[16:46] <sbeattie> tyhicks: ^
[16:46] <sarnold> and I'm on community
[16:46] <ratliff> ubuntu-terminal-app
[16:46] <sarnold> thanks ratliff :)
[16:46] <tyhicks> yep
[16:46] <tyhicks> and zmqpp after that
[16:47] <sarnold> lets hope lukasz fixes the ftbfs :)
[16:47] <sarnold> it sounded promising but he mentioned silos and I lost track
[16:47] <tyhicks> sarnold: a fixed upload is in the unapproved queue
[16:47] <tyhicks> sarnold: see the bug report
[16:48] <tyhicks> https://bugs.launchpad.net/ubuntu/+source/zmqpp/+bug/1617005/comments/4
[16:48] <tyhicks> sarnold: might be worth kicking that build off while looking at ubuntu-terminal-app :)
[16:48] <tyhicks> does anyone have anything else?
[16:49] <sarnold> heh, ubuntu-terminal-app doesn't even show up in umt search :/
[16:49] <tyhicks> I'm confused by that one
[16:49] <tyhicks> maybe ratliff can get you more info?
[16:49] <ratliff> https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1625074
[16:50] <tyhicks> ratliff: it isn't in Ubuntu: https://launchpad.net/ubuntu/+source/ubuntu-terminal-app
[16:50] <ratliff> the code is in launchpad and linked to off of that MIR
[16:51] <tyhicks> lets discuss this outside of the meeting so that everyone else can go about their day
[16:51] <tyhicks> jdstrand, mdeslaur, sbeattie, jjohansen, sarnold, ChrisCoulson, ratliff: Thanks!
[16:51] <tyhicks> #endmeeting
[16:51] <meetingology> Meeting ended Mon Sep 26 16:51:40 2016 UTC.
[16:51] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-09-26-16.31.moin.txt
[16:51] <mdeslaur> thanks tyhicks
[16:51] <ratliff> thanks, tyhicks!
[16:51] <sbeattie> tyhicks: thanks!
[16:53] <sarnold> thanks tyhicks!
[16:55] <jdstrand> thanks tyhicks :)