text: #ubuntu-meeting-2 2015-04-07
   * dsmythies realizes that we changed from standard time to daylight savings time last month, and so the doc team meeting is not for another hour.
  <dsmythies> #startmeeting
  <meetingology> Meeting started Tue Apr  7 17:31:12 2015 UTC.  The chair is dsmythies. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
  <meetingology> Available commands: action commands idea info link nick
  <dsmythies> #chair dsmythies GunnarHj
  <meetingology> Current chairs: GunnarHj dsmythies
  <dsmythies> Who is here for the doc team meeting?
  <bregma> o/
  <GunnarHj> o/
  <dsmythies> GunnarHJ: I made you a chair person
  <GunnarHj> dsmythies: Saw it. You are fast today. :)
  <dsmythies> we will wait a moment for ian
  <dsmythies> O.K. ian is here. let's start.
  <dsmythies> Just to report on some stuff rraom the last month: We did point releases of the 12.04 and 14.04 serverguides.
  <dsmythies> And Gunnar has been getting 15.04 desktop guide ready for release day.
  <GunnarHj> Except for the translations (due Thursday)
  <dsmythies> Anybody want to comment of any other activites from last month?
  <dsmythies> O.K. moving on...
  <dsmythies> from old actions, Hannie isn't here, so we'll leave that one. Gunnar, care to comment on desktop slidehsow?
  <GunnarHj> Not much to say. It will be done in vivid+.
  <dsmythies> ... just reading the bug report... Oh, ya. O.K.
  <dsmythies> other old actions done, so let's go to new business.
  <dsmythies> Desktop and Unity 8: I know nothing about setting up a new project. Nor do I have the capacity to take on such a project.
  <bregma> I have an interest in contributing (and I cna probably set up a project) but I am not a writer
  <bregma> also, the Unity 8 desktop will be in flux for the next several months
  <bregma> but I would like to see a start on the guide (or equivalent) earlier rather than later
  <GunnarHj> bregma: What does "in flux" mean?
  <dsmythies> before we go into a new project, should we access if there is enought interest from people willing to contribute?
  <bregma> I do not believe the final appearance (or event functionality) is fully decided yet
  <GunnarHj> ok.
  <dsmythies> assess instead access
  <GunnarHj> As I mentioned on list, my main concern is the seemingly lack of contributors in the team.
  <dsmythies> Agree.
  <bregma> I think there are some people in Canonical's Desktop team who can be tasked with making some contributions, but none of them are writers
  <bregma> I do believe there is buy-in there, though
  <dsmythies> bregma: Please know that I am not a writer either. I just seem to have stumbled into this roll.
  <bregma> OK
  <GunnarHj> bregma: If you look at the desktop branch, you can see that the number of contributors lately is *very* limited. It's kind of a crisis.
  <bregma> I don't really want to see a new desktop environment rolled out without some sort of guide, so my question is:  how can we drum up enough contribution interest from the community?
  <dsmythies> We have fought with that question for years.
  <bregma> indeed
  <GunnarHj> Possibly the fact that it is a new desktop env. will make a difference - but I'm not sure.
  <bregma> the fact that the desktop has been fairly unchanged for several years means there hasn't been a lot for contributors to do
  <bregma> perhaps getting Canonical's community team to help drum up interest through their usual social media stuff would be a good start?
  <GunnarHj> When Unity 7 was new, Jeremy Bicha did an amazing amount of work. But wasn't he a Canonical emploee at the time?
  <dsmythies> O.K. Sounds like a significant project. It will need a champion.
  <dsmythies> bregma: you willing to take the lead?
  <bregma> I am willing to volunteer, but I have no idea about any doc development workflow, so I would need guidance with that
  <dsmythies> We have spent significant time of recent getting our wiki pages up to date.
  <GunnarHj> bregma: We can certainly help with the workflow part. It would be great if you could announce the need on the list as a starter.
  <bregma> sure, sounds good
  <dsmythies> for doc workflow, suggest the you start by learning how to work within the exisiting desktop help enviroment.
  <dsmythies> what is the timeline for this unity 8?
  <bregma> actually, I'm familiar with that, as far as building docs in various formats locally and getting changes in, but the rest is only a vague handwaving thing in my mind
  <GunnarHj> bregma: Is the plan to create a totally separate set of docs for Unity 8?
  <GunnarHj> bregma: Should it be distributed as a package, or only on the web?
  <bregma> I would go for a totally separate doc, yes, since for at least a while you can have either or both installed on your system at the same time
  <bregma> and the timeline for replacing Unity 7 with Unity 8 is not yet clear
  <GunnarHj> Ok, that speaks for basically creating a skeleton branch based on the ubuntu-docs branch.
  <pmatulis> hi guys
  <dsmythies> Oh, so eventually the current dektop help will not continue.
  <bregma> yeah, that was my first thought
  <dsmythies> pmatulis: Hi. we are on Unity 8 stuff.
  <pmatulis> ok, sorry for being late
  <bregma> yes, eventually I expect Unity 7 will not be included in newer versions of Ubuntu, so neither will the docs
  <dsmythies> GunnarHj: Sound like the new stuff will need to be a package.
  <bregma> is that how the Unity 7 docs get installed today, as a package?
  <GunnarHj> bregma: Yes.
  <GunnarHj> bregma: (and on the web)
  <bregma> then separate guides in separate packages is the easiest approach, and something I know how to do
  <GunnarHj> bregma: For Unity 7 we are using Mallard.
  <dsmythies> bregma: can I set action for you to drum up interest and detail some sort of project plan? The timeline is future sometime T.B.D.
  <bregma> dsmythies, yes please, I will take repsonsibility and the timeline will be to target an initial version for release in 15.10
  <dsmythies> #action bregma to stimulate interest in unity 8 dektop help guide.
  <meetingology> ACTION: bregma to stimulate interest in unity 8 dektop help guide.
  <dsmythies> #action bregma to create project plan for unity 8 dektop help guide.
  <meetingology> ACTION: bregma to create project plan for unity 8 dektop help guide.
  <dsmythies> bregma: I think you will find an initial target of 15.10 aggressive.
  <imnichol> bregma, I'm not incredibly knowledgeable about this process, but if you need help with anything I'd be willing to assist.
  <bregma> thanks
  <dsmythies> are we done with unity 8 discussion?
  <GunnarHj> Think so.
  <dsmythies> I will try to have 15.04 preliminary help.ubuntu.com content by early next week. I always like to do preliminaty first, so as to identify surprises, so that release day is smooth.
   * bregma nods
  <GunnarHj> dsmythies: Is "10.10" in the agenda a typo?
  <dsmythies> No. 10.10 EOL (Serverguide) is end of April.
  <dsmythies> the plan is to move to it once 15.04 final is done.
  <dsmythies> Oh. I mean 10.04
  <GunnarHj> dsmythies: Thought so. ;)
  <dsmythies> I'll fix agenda later.
  <dsmythies> pmatulis: I mentioned the point releases of serverguide earlier.
  <dsmythies> Anything from serverguide or manual or wiki?
  <GunnarHj> Let's move to the meeting time.
  <dsmythies> pmatulis: Does the change to daylight savings time affect your preferred meeting time?
  <pmatulis> dsmythies: hi
  <pmatulis> dsmythies: in a meeting :) .  playing hooky here
  <pmatulis> dsmythies: so if it is 30 min earlier *now* i will be good
  <pmatulis> dsmythies: but yeah, in the winter i would be 1 hour behind
  <pmatulis> dsmythies: so i guess that mean 90 minutes earlier
  <pmatulis> dsmythies: or did i get that backwards?  :)
  <dsmythies> O.K. I am confused. so are you saying 17:00 would be bteer for you? or are you saying 16:00 would be better for you? Do others have input?
  <GunnarHj> I'm flexible.
  <dsmythies> I'm flexible.
  <pmatulis> dsmythies: 16:00
  <dsmythies> O.K. that is 8:00 a.m. my time, which is fine.
  <dsmythies> and in winter that would be 7:00 a.m. my time, which is still fine.
  <pmatulis> alright, action me to change the wiki?
  <dsmythies> I believe pleia2 is also on the west coast of North America, and 7 might be a little early for her.
  <dsmythies> O.K. ;ets try it.
  <dsmythies> O.K. lets try it.
  <dsmythies> #action pmatulis: adjust wiki and banner meeting times.
  <meetingology> ACTION: pmatulis: adjust wiki and banner meeting times.
  <dsmythies> O.K. anything else anybody?
  <pleia2> I am west coast, but I struggle to attend these meetings anyway, so please do whatever works for all of you
  <GunnarHj> I don't have anything else. (Already in another IRC meeting.)
  <dsmythies> pleia2: O.K. thanks for chiming in.
  <dsmythies> O.K> I'll end the meeting.
  <dsmythies> #endmeeting
  <meetingology> Meeting ended Tue Apr  7 18:28:36 2015 UTC.
  <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.2015-04-07-17.31.moin.txt
  #ubuntu-meeting-2 2016-04-11
  <mdeslaur> \o
  <tyhicks> hello
   * sbeattie waves
  <tyhicks> #startmeeting
  <meetingology> Meeting started Mon Apr 11 16:34:11 2016 UTC.  The chair is tyhicks. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
  <meetingology> Available commands: action commands idea info link nick
  <tyhicks> The meeting agenda can be found at:
  <tyhicks> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
  <tyhicks> [TOPIC] Weekly stand-up report
   * tyhicks kicks the bot
  <tyhicks> mdeslaur: you're up
  <mdeslaur> I'm on community this week
  <mdeslaur> I have patch piloting tomorrow
  <mdeslaur> and I'm working on an embargoed issue
  <mdeslaur> that's it, sbeattie, you're up
  <sbeattie> I'm on bug triage this week
  <sbeattie> I'm working on testing glibc updates, trying to figure out what breaks with pt_chown disabled.
  <sbeattie> I've got a kernel USN to write I guess (not sure what the kernel team did there)
  <sbeattie> I've got some apparmor stuff to do (patch review)
  <sbeattie> That's probably it for me this week
  <sbeattie> tyhicks: you're up
  <tyhicks> I'm on cve triage this week
  <tyhicks> apparmor 2.10.95 landed in xenial over night so I'll be watching for any issues there
  <tyhicks> I have some ubuntu-core-launcher MPs to review for jdstrand
  <tyhicks> still have some pending ecryptfs patch reviews
  <tyhicks> would also like to do some triaging/updates for Touch
  <tyhicks> that's it for me
  <tyhicks> sarnold: you're up
  <tyhicks> sorry
  <tyhicks> jjohansen: you're up
  <sarnold> \o/ apparmor landing
  <jjohansen> I'm still working on apparmor this week
  <tyhicks> you say that like there is an end in sight :)
  <jjohansen> I have an upstream patchset of bug fixes to finish putting together and push up
  <jjohansen> and then it will be back to fixing bugs and issues in the newly landed apparmor 3.5
  <jjohansen> and of course watching for any issues that may surface from 2.10.95 landing
  <jjohansen> thats it for me sarnold you are up
  <sarnold> i'm in the happy place this week
  <sarnold> I'm working on mirs, neutron-vpnaas, aodh, barbican, designate, it's unlikely I'll get them all this week but I might get lucky, aodh is apparenhtly a piece from ceilometer
  <sarnold> and I'd like to test out shiny new apparmor stacking
  <sarnold> that's it for me, chrisccoulson?
  <chrisccoulson> Last week I made quite a bit of progress on automated testing in Oxide (I got all of our existing QML tests also running in single-process, which means we can officially support that now)
  <tyhicks> nice!
  <chrisccoulson> I plan to do more of the same this week - I'm adding some compiled unit-tests for bits of the API (most of our existing tests are more integration tests than unit tests). Then I plan to add a framework for writing unit-tests for internal classes
  <chrisccoulson> I need to also do some feature work (not much of that has happened over the last couple of weeks). I'll probably be experimenting with scrollbars to see how we can support the design requirements for those
  <chrisccoulson> And there's probably going to be a Firefox update
  <chrisccoulson> That's me done
  <tyhicks> thanks
  <tyhicks> [TOPIC] Highlighted packages
  <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.
  <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.
  <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/python-requests-kerberos.html
  <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/maildrop.html
  <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/dcmtk.html
  <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/xml-light.html
  <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/loganalyzer.html
  <tyhicks> lots of good ones in there this week
  <tyhicks> [TOPIC] Miscellaneous and Questions
  <tyhicks> Does anyone have any other questions or items to discuss?
  <tyhicks> mdeslaur, sbeattie, jjohansen, sarnold, ChrisCoulson: Thanks!
  <tyhicks> #endmeeting
  <meetingology> Meeting ended Mon Apr 11 16:53:06 2016 UTC.
  <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.2016-04-11-16.34.moin.txt
  <jjohansen> thanks tyhicks
  <sarnold> thanks tyhicks!
  <sbeattie> tyhicks: thanks.
  <mdeslaur> thanks tyhicks!
  #ubuntu-meeting-2 2016-04-12
  <mdeslaur> \o
  <pitti> o/
   * slangasek waves
  <pitti> infinity went to bed very late, I don't expect him to show up
  <slangasek> who's chair today?
  <pitti> chair: infinity, backup: kees
  <slangasek> wiki says infinity with kees as backup
  <pitti> not that we have much of an agenda
  <pitti> this is the last meeting of the old TB
  <mdeslaur> did someone bring cake?
  <slangasek> kees has not made it to TB meetings much lately; probably an action for the board post-election to review the meeting timing
  <slangasek> (regardless of turnover)
  <pitti> infinity owns three dragged-on actions, so they will just be postponed again
  <pitti> and nothing on ML and community bugs, so I guess that's already a "kthxbye", unless you have something?
  <mdeslaur> I don't have anything
  <slangasek> nothing except my own carry-over action
   * stgraber waves
  <stgraber> and nothing to bring up either
  <slangasek> so shall we adjourn this meeting that had no chair to call it to order? ;0
  <pitti> +1 :)
  <mdeslaur> +1 bye!
   * pitti tips hat and bows, it's been an honor to serve on the TB
  <slangasek> thanks :)
  <mdeslaur> pitti: thanks! :)
  #ubuntu-meeting-2 2017-04-11
  <kees> o/
  #ubuntu-meeting-2 2018-04-10
   * tsimonq2 waves, albeit a few mins early
  <mdeslaur> \o
  <kees> o/
   * slangasek waves
  <mdeslaur> hi kees
  <mdeslaur> hi slangasek
  <kees> 3 ... anyone else?
  <slangasek> I understand stgraber is on vacation this week, no idea what that implies for his TB meeting attendance
  <kees> no quorum with 3. whee
  <slangasek> is 3 not quorum?
  <slangasek> I thought we've certainly been treating it as such
  <kees> oh!
  <kees> ok
  <kees> #start-meeting
  <slangasek> no-dash?
  <kees> #startmeeting
  <meetingology> Meeting started Tue Apr 10 19:04:35 2018 UTC.  The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
  <meetingology> Available commands: action commands idea info link nick
  <kees> ah
  <kees> action review:
  <kees> ACTION: flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns.
  <slangasek> I haven't seen anything on the list
  <mdeslaur> doesn't look like he did
  <slangasek> and he's currently off irc
  <kees> yeah
  <tsimonq2> Wimpress is his new nick.
  <slangasek> oh
  <slangasek> Wimpress: ^^ ?
  <Wimpress> o/
  <kees> ACTION: tsimonq2 to propose patches to maintenance-check regarding Lubuntu Next (done in https://code.launchpad.net/~tsimonq2/ubuntu-archive-publishing/lubuntu-next-support-cycle-adjustment/+merge/342475
  <kees> oh
  <Wimpress> This is not forgotten.
  <Wimpress> I'll try and get round to this in the next week.
  <mdeslaur> Wimpress: what's with the disguise?
  <tsimonq2> mdeslaur: #blameflocculant
  <Wimpress> Long story.
  <mdeslaur> hehe
  <Wimpress> But that ^
  <Wimpress> We've already dropped a bunch a PPA and repos from Welcome as a start on  this.
  <Wimpress> But I will post to the ML with a full proposal soon
  <mdeslaur> ack, thanks
  <kees> cool. deferred
  <slangasek> Wimpress: ok; bearing in mind that the TB's request was not that you drop the support for third-party repos necessarily, but that you disclose to the user what is happening
  <kees> tsimonq2: how about your action?
  <Wimpress> slangasek: Yes, I know. But I felt this was a good time to review what we were listing.
  <tsimonq2> kees: It's done; I'm the one who modified the agenda with the link in there. ;)
  <slangasek> yes, I reviewed and merged the change
  <slangasek> tsimonq2: have you verified that the result is correct in the archive metadata?
  <kees> oh durp
  <tsimonq2> slangasek: No; where can I do that?
  <slangasek> tsimonq2: Packages.gz
  <slangasek> tsimonq2: Supported field
  <kees> ACTION: infinity to call for confirmation of LTS status from all flavours.
  <tsimonq2> One minute then; you're free to move on to other items.
  <kees> no infinity so deferred
  <slangasek> tsimonq2: qlubuntu-default-session still shows as Supported: 3y which I think indicates it didn't have the intended result yet; you and I can iterate
  <kees> ACTION: infinity to ask maas team to prepare SRU exception policy Ã  la CurtinUpdates
  <kees> also deferred
  <kees> agenda items...
  <kees> [slangasek] - Review of the seeded snaps policy
  <slangasek> hello
  <slangasek> [LINK] https://wiki.ubuntu.com/UbuntuSeededSnaps
  <tsimonq2> slangasek: The source package is shared. That's not an accurate representation.
  <slangasek> tsimonq2: afaik supported fields are per-binary, not per-source; anyway, feel free to find one that you know should be 9m and check the result :)
  <slangasek> kees, mdeslaur: I didn't send any follow-up emails, I think the agreement last time was that TB members would review this spec in their own time and we could discuss at this meeting.  Did you have a chance to review the spec?
  <mdeslaur> I did review the spec, I have a few questions
  <tsimonq2> slangasek: Ah, so indeed, it didn't set correctly.
  <tsimonq2> #action tsimonq2 to investigate why the Lubuntu Next support time modifications are not set correctly
  <meetingology> ACTION: tsimonq2 to investigate why the Lubuntu Next support time modifications are not set correctly
  <tsimonq2> Anyway, sorry, carry on.
  <slangasek> mdeslaur: excellent, I'm happy to make up answers :)
  <mdeslaur> The spec doesn't define who acts as the gatekeeper between core devs and publishing a snap directly to users
  <mdeslaur> like the way it is currently handled
  <slangasek> in the sense of archive review?
  <mdeslaur> yes. In the sense that currently a core dev can't push an update directly to users
  <slangasek> ah; so perhaps more in the sense of SRU
  <mdeslaur> without going through the sru team, etc
  <slangasek> yes; I think the design of the snap store, and the relative isolation of snaps, means we should aim to have less process around this generally,
  <slangasek> because e.g. reverts are a lot easier, and eventually should be drivable with health checks
  <slangasek> etc
  <slangasek> so at this time I wasn't aiming to dictate any gatekeeping around this, or to forklift import the SRU policy
  <kees> i only had one question: how are seeded snaps distinguished from third party snaps? given the higher policy requirements for seeded snaps, end users may only want seeded snaps
  <slangasek> mdeslaur: do you think that's ok for now, or do you think we need gatekeepers initially?
  <mdeslaur> won't there be third party seeded snaps too?
  <mdeslaur> slangasek: I personally think this makes becoming a core-dev or attempting to steal core-dev credentials much more attractive for people with bad intentions
  <slangasek> ok
  <kees> mdeslaur: seeded snap policy says everything has to be in LP (source and builds), so i think no 3rd party?
  <mdeslaur> "...to be included in an Ubuntu image, a snap should have as its publisher either the upstream..."
  <slangasek> mdeslaur: in practice, we don't gate uploads to the devel series by core-devs, after initial NEW processing; so it's a difference in window of opportunity (you can upload a hostile snap and have it instantly take effect for stable users, vs. having to upload to devel and wait and see)
  <jbicha> that's interesting for the use case of Firefox where we got mozilla building the snap
  <slangasek> mdeslaur: and in practice the store doesn't give us many layers of gatekeeping against collaborators
  <mdeslaur> slangasek: right, but the devel series is a buffer that (in theory) allows review by others, and damage can be reverted before hitting users
  <slangasek> kees: so in this case you're defining third-party as "not built on trusted infrastructure"?
  <kees> i guese, yes. "snaps installed by default we should ensure that they are built from source in the same trusted Launchpad environment in which debs are built"
  <slangasek> yes, firefox is an interesting case, and there are different requirements that are in tension.  I think we should punt on firefox in the context of this discussion
  <slangasek> (firefox snap is not seeded in 18.04 desktop, AFAIK; we have time)
  <kees> the policy (source can't disappear, built on LP) is a higher bar, so making those discoverbale seems like it'd have value to end users
  <kees> beyond that, i like the policy
  <slangasek> kees: anyway, to your question of distinguishing them, the intent is that this be surfaced as metadata in the snap store, which the store could expose to the end user over the snapd api
  <kees> perfect
  <jbicha> (yes, AFAIK firefox snap isn't proposed for inclusion in Ubuntu by default yet)
  <slangasek> I'm working with the store team on the implementation details, but yes, it's important that this be auditable and not taken on faith that a given snap is done correctly :)
  <kees> mdeslaur: are your questions/concerns addressed?
  <mdeslaur> I like the policy as it applies to snaps built in launchpad from known sources, and security support has been commited to
  <mdeslaur> I don't know how third party or upstream snaps fit into that
  <slangasek> mdeslaur: per current policy, a "third party" or "upstream" snap is fine but they still need to build the binary on LP to comply with this policy
  <mdeslaur> how the mechanism for taking control of that snap if adequate security isn't being provided?
  <mdeslaur> s/how/what's/
  <jbicha> (and the third party needs to be in a LP team approved by the DMB)
  <mdeslaur> Let's say we allow an upstream snap, built on launchpad in bionic, and upstream decides to no longer build security updates for the bionic snap once the next LTS rolls out, for example
  <slangasek> mdeslaur: today, we would try to talk to the publisher first, or the store team as necessary, to get collaborator access and publish our updates to the stable/ubuntu-XX.YY channels
  <slangasek> jbicha: that's an interesting point; I don't think it follows from the current policy as written
  <kees> slangasek, mdeslaur: sounds like security support policy needs to get fleshed out more? should that continue in email?
  <jbicha> slangasek: oh
  <slangasek> note that the snap store doesn't actually use launchpad teams; publishers / collaborators are implemented only store side and are defined in terms of assertions and keys
  <slangasek> so we can't actually enforce that every collaborator on a third-party snap is part of a DMB-approved LP team
  <kees> [action] slangasek and mdeslaur to more clearly define third party seeded snap security policy
  <meetingology> ACTION: slangasek and mdeslaur to more clearly define third party seeded snap security policy
  <kees> how's that look?
  <slangasek> if that is the action from mdeslaur's POV, sure :)
  <mdeslaur> It may be easier to get this accepted in two steps: 1- community-maintained, launchpad-built snaps, and then 2- thirty party snaps
  <kees> 20 minutes left, so let's move on for now...
  <kees> [tsimonq2] - The rationale for snapd being in the platform seed when flavors weren't polled first.
  <mdeslaur> ok
  <tsimonq2> Hi.
  <tsimonq2> I am wondering, out of curiosity, why snapd was added to the desktop-common seed without flavors being consulted: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.bionic/revision/2056
  <tsimonq2> I oppose to shipping snapd in Lubuntu by default due to some serious usability concerns that I have raised with the Snapcraft team, as well as bug 1730159 among other things.
  <tsimonq2> This isn't an issue right now, because Lubuntu doesn't pull in recommends and I've manually blacklisted it just in case, but it becomes an issue when we turn off no-follow-recommends at the beginning of next cycle.
  <tsimonq2> I would like to request the removal of snapd from desktop-common, even as recommended, because Lubuntu does not want to ship this as part of our default install, unless of course it's mandated by the Technical Board. I would also like to know why this decision was made without asking flavors, unless I am missing some historical context or something else here.
  <tsimonq2> Thanks.
  <slangasek> right
  <slangasek> so, I have certainly defended the principle recently that the desktop-common seed in particular should be subject to consensus among the desktop flavors, and should not be used to force things into the common platform over objections ;)
  <tsimonq2> You have. :)
  <slangasek> you will however note that I am the committer of that revision and are right to call out the disconnect
  <slangasek> so here's my position
  <slangasek> the fact that it's in the desktop-common seed is actually an implementation detail
  <slangasek> from the perspective of Canonical, and the Foundations Team, snapd is now part of the standard Ubuntu experience
  <slangasek> anyone who installs Ubuntu, in any of its forms, should be able to 'snap install' the same way they're able to 'apt install'
  <slangasek> in practice it's separately seeded in desktop-common and in server, but the intent is that it's part of the common platform experience
  <slangasek> this is subject to TB review, of course
  <tsimonq2> Right, and this is me bringing it to TB review. :)
  <kees> seems like snapd should be part of the per-flavor *-desktop ?
  <slangasek> but that at least gives the rationale for not consulting flavors - it was a platform-level decision
  <kees> or *-minimal, or something?
  <tsimonq2> And the "standard Ubuntu experience" is defined by Canonical, not by the Ubuntu Technical Board or another similar body? Or does this come from sabdfl?
  <slangasek> depending on the result of TB review, we can move it to a more appropriate seed(s) for clarity
  <slangasek> tsimonq2: the TB doesn't often get asked to sign off on platform changes up front
  <slangasek> I don't think the upstart->systemd move was TB-ratified, to give one example
  <tsimonq2> kees: I agree with you.
  <slangasek> but the TB is certainly the right forum for appeal
  <kees> seems like even this doesn't need to come to TB. snap availability should be a flavor-specific option, yes?
  <kees> slangasek: by "standard Ubuntu experience" do you mean "all ubuntu flavors"?
  <tsimonq2> kees: Correct, but we weren't given the choice.
  <slangasek> kees: yes
  <kees> aaah
  <kees> hm
  <mdeslaur> just like all flavours use the standard kernel, and repos, etc.
  <kees> right
  <kees> okay, I misparsed the "standard Ubuntu" to mean "Ubuntu-the-flavor"
  <tsimonq2> But, "standard Ubuntu experience" is Canonical-defined? Is that at least public?
  <kees> You really mean "universal Ubuntu experience"
  <mdeslaur> I think it would be a disservice to users to have a specific flavour be missing some software installation sources
  <slangasek> kees: yes, sorry
  <tsimonq2> mdeslaur: Even if it's one command away to install and it's not being used by default, at all?
  <tsimonq2> Er, s/used/utilized/.
  <kees> tsimonq2: if bug 1730159 was solved, how would you feel about Lubuntu with snapd installed?
  <tsimonq2> kees: Much more inclined.
  <tsimonq2> But I would still take an additional look.
  <mdeslaur> tsimonq2: having a webpage instruct a user to do a "snap install" but then have a special section how to do it on a specific flavour would be a disservice to users
  <kees> okay, then I see two issues here: the *specific* case of snapd in Lubuntu (seemingly solved with bug 1730159 getting fixed), and the desire to have a policy on things getting added to all flavors without notification of the flavors.
  <mdeslaur> tsimonq2: but if you have technical objections that can be fixed, then I'm sure they could be addressed
  <tsimonq2> mdeslaur: I see.
  <tsimonq2> kees: Bingo.
  <kees> slangasek: you've already commented on that bug; how feasible would it be to solve this before 18.10?
  <kees> tsimonq2, mdeslaur: it sounds like that for 18.04, Lubuntu will need that extra instruction, since it _isn't_ installed there currently.
  <slangasek> tsimonq2: so, "does this come from sabdfl" - Canonical is his company, the company has put a lot of money into developing the snap store and experience, and therefore you can expect the barrier for overturning such a platform decision to be somewhat high (even to the point that yes, sabdfl might directly put his thumb on the scale).  As mdeslaur says, Canonical's interest here would instead be
  <slangasek> to focus on improving snapd so that it met the needs of our flavors
  <tsimonq2> kees: Does the TB expect me to put snapd back?
  <tsimonq2> I can, if needed.
  <kees> tsimonq2: I don't know; that's why I'm bringing that up -- as things stand, it's not installed. but it's a Recommend and Lubuntu doesn't install Recommends by default, so ... everything is working as expected right now
  <slangasek> kees: I would say that LP: #1730159 should even be solved in 18.04 (though perhaps not before GA)
  <kees> the statements made about it seem to aim at 18.10 when those defaults will change for lubuntu
  <tsimonq2> slangasek: OK. I am not saying that I don't like snapd and I don't want to ship it, I'm saying that I see shortcomings to doing that before some problems are solved.
  <kees> okay, almost out of time.
  <kees> should we keep an action about flavor-wide default package notifications?
  <tsimonq2> I think so.
  <slangasek> perhaps you want to scope that to "daemons"
  <tsimonq2> kees: installed by default> ack
  <slangasek> since that's really the only thing that makes snapd problematic, compared to all the other changes Foundations makes unsupervised
  <kees> that seems reasonable to me.
  <mdeslaur> I think that's reasonable also
  <tsimonq2> I can remove snapd from the Lubuntu blacklist, but if Canonical wants snapd, they can raise it to a Depends. :)
  <kees> tsimonq2: are you will to write up the language for such a policy? then we can review it on email and take it to the next meeting?
  <tsimonq2> Absolutely.
  <kees> [action] tsimonq2 to email proposed policy for flavor-notification of daemons being added to all flavors (e.g. snapd into desktop-common)
  <meetingology> ACTION: tsimonq2 to email proposed policy for flavor-notification of daemons being added to all flavors (e.g. snapd into desktop-common)
  <kees> okay, that's time! :)
  <kees> #endmeeting
  <tsimonq2> o/
  <meetingology> Meeting ended Tue Apr 10 20:01:06 2018 UTC.
  <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2018/ubuntu-meeting-2.2018-04-10-19.04.moin.txt
  <slangasek> hah
  <slangasek> thanks, all :)
  <kees> thanks!
  <mdeslaur> thanks everyone!
  <tsimonq2> Thanks! (now that my connection is better)
  