#ubuntu-meeting-2 2015-02-03
<dsmythies> #startmeeting Ubuntu Docs
<meetingology> Meeting started Tue Feb  3 17:29:41 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
<meetingology> Current chairs: dsmythies
<dsmythies> Anybody here for Ubuntu Docs team meeting?
<imnichol> as an observer
 * PaulW2U says me too
<dsmythies> O.K. this could be a real quick meeeting.
<dsmythies> Myself, I am quite unprepared for this meeting, and the adgenda is out of date.
<pmatulis> hello, i'm here
<pmatulis> although currently in a work meeting :)
<dsmythies> I'm just reviewing the minutes from last time and any still relveant adgenda items...
<pmatulis> dsmythies: i would love to remove stuff but i don't know if people are still working on them
<dsmythies> Does anybody have anything they want to bring up?
<pmatulis> the cloud docs are up, that's something
<dsmythies> Clouddocs: I thought I would post an announment on the Ubuntu forums sub-forum you set up. I can not recall if we announced them on the mail list, but if not we should.
<dsmythies> #action dsmythies make some announcements about the Canonical Clouddocs
<meetingology> ACTION: dsmythies make some announcements about the Canonical Clouddocs
<dsmythies> On Sunday night, I made a mistake on an update for help.ubuntu.com that left the new Canonical clouddocs site without any .css file for one day. Sorted out now.
<dsmythies> reference: https://help.ubuntu.com/lts/clouddocs/en/Intro.html
<pmatulis> dsmythies: your proposal for the sg was to change trunk away from 14.04 when 14.04.1 came out.  that was july 24th.  what do you want to do?
<pmatulis> (and 14.04.2 is in a couple of days)
<dsmythies> I'd have to remind myself, but I still do not see any reason to deviate the trunk from 14.04 yet. i.e. I haven't yet observed any non-backwards compatible changes. (which doesn't mean they don't exist, I just don't know about them if they do.)
<dsmythies> We never did do a 14.10 non-stable release, and I don't know about 15.04, but why bother?
<pmatulis> well eventually we are going to get bit
<pmatulis> i still don't like the idea but i can understand the convenience
<pmatulis> especially since we get so little contributions
<dsmythies> Yes, so at that point we lock down the 14.04 series branch and the trunk continues. But until then why double the work of maintaining two branches?
<dsmythies> The thinking was if you or, some other champion, wanted to start towards some other markup language, then would lock down 14.04 and the trunk would become the devleopment branch with a good long time until 16.04 lts.
<dsmythies> Peter: I was typing and didn't see your last two comments. Yes, I am always trying to minimize labour, becuase there isn't any labout available.
<pmatulis> dsmythies: do you use bzr 'shared repositories' when you do your committing work?
<dsmythies> I guess not because I don't know what you mean. I use "bzr commit -m 'bla bla bla' then bzr push
<pmatulis> dsmythies: well with shared repos things go a lot faster b/c the changes metadata is shared.  you should try it.  it might make the labour easier if by labour you mean having a lot of dowload waiting time
<pmatulis> http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
<pmatulis> dsmythies: btw, a colleague of mine is contributing an ActiveDirectory/SSSD sub-chapter.  it's based on 14.04 so no worries about compat. problems
<dsmythies> I mean doing the same thing twice, once for each branch. Is this "shared" thing something that could have been used for backporting your reporting bugs patch to precise?
<pmatulis> dsmythies: no
<pmatulis> dsmythies: thanks for reminding me of that.  and i really did that oopsies way to quick.  sorry about that one
<dsmythies> imnichol and/or PaulW2U: please chime in or whatever if you want. We are just discussing stuff.
<pmatulis> dsmythies: btw, was 12.04 updated on help recently?
<pmatulis> dsmythies: i know i merged quite a few fixes for 12.04
<dsmythies> Peter: Let me catch up via the reference you gave. (Not now, but afterwards).
<dsmythies> Peter: I did do a point release of 12.04, but I don't think since some of your recent changes.
<pmatulis> dsmythies: ok
<dsmythies> I think we should do a much more advertised point releaae of both 12.04 and 14.04. By "advertiesed" I mean post on the translators e-mail list that it is pending and give them a few weeks to do their stuff.
<dsmythies> for example. the italian serverguide had 0 string to translate and then it went to 50 or so, but how would they know if we don't tell them? (since it isn't on their list, why I do not know)
<pmatulis> dsmythies: agreed.  and i would like to do the 12.04/14.04 updates but i'm still a little shell-shocked from what happened during my last attempt
<dsmythies> we will just work more closly this time, and do a merge proposal for help.ubuntu.com. I would like to try to implement my relative URL thing, instead of absolute, also.
<pmatulis> dsmythies: yep
<pmatulis> dsmythies: having introduced nick to you and gunnar was good
<dsmythies> #action dsmythies pmatulis prepare for and execute point releases for serverguides 12.04 and 14.04 quickly before 15.04 crunch time.
<meetingology> ACTION: dsmythies pmatulis prepare for and execute point releases for serverguides 12.04 and 14.04 quickly before 15.04 crunch time.
<dsmythies> Peter, I was already working with Nick via problem reports I had entered. But yes, thanks.
<pmatulis> dsmythies: should we be stating on the s/g focus page for contributors to be using 14.04?  then the onus would be on us to see whether 14.04 stuff works with a newer release instead of the more dangerous 'hope that 15.04 works on 14.04' option
<pmatulis> dsmythies: i would be more comfortable with the former
<dsmythies> Good idea. However, the build tools should be at least 14.10 based, until my yelp-tools and telp-xsl backport request gets somewhere. It seems to have stalled. As far as I know I have completed the testing requirements.
<pmatulis> dsmythies: right, it's easier to manage 3 people
<pmatulis> dsmythies: yep, ubuntu backports is a mechanism but there is no promise of that working at all
<dsmythies> Well, it is a year now that I have wanted yelp-tools and yelp-xsl to be more recent.
<dsmythies> imnichol and/or PaulW2U: Can we help you with anything?
<pmatulis> dsmythies: i think we should either use at least 14.10 as a build server or use a PPA
<pmatulis> dsmythies: did you give me an action to send a help request to the mailing lists (ubuntu-doc and ubuntu-server)?
<dsmythies> The PPA exisits. Gunnar made it. Since I always forget how, I made web notes to include and later on remove the PPA. Servers work different than desktop for PPA stuff.
<dsmythies> #action pmatulis send a help request to the mailing lists (ubuntu-doc and ubuntu-server)
<meetingology> ACTION: pmatulis send a help request to the mailing lists (ubuntu-doc and ubuntu-server)
<dsmythies> I'll send anyone a link to y PPA web notes, if they ask. But I will include it herein.
<dsmythies> I'll send anyone a link to y PPA web notes, if they ask. But I will NOT include it herein.
<dsmythies> Are we done?
<pmatulis> dsmythies: i am making changes to the focus page re contributors using 14.04
<dsmythies> #action pmatulis make changes to the focus page re contributors using 14.04
<meetingology> ACTION: pmatulis make changes to the focus page re contributors using 14.04
<pmatulis> dsmythies: updated the page.  want to check and get it over with?
<dsmythies> I'll close the meeting after I find and include a link to the yelp stuff PPA.
<dsmythies> Peter: I'll do that off-line. Give me a bit.
<dsmythies> Reference for the yelp stuff ppa: https://launchpad.net/~ubuntu-core-doc/+archive/ubuntu/ppa
<dsmythies> #endmeeting
<meetingology> Meeting ended Tue Feb  3 18:34:51 2015 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.575.979.1648.29.moin.txt
<dsmythies> pmatulis O.K. on the changes.
#ubuntu-meeting-2 2015-02-17
<mdeslaur> \o
 * slangasek waves
 * infinity is very not here today.
<mdeslaur> infinity: uh, meaning?
<infinity> mdeslaur: Mentally, I mean.  Completely checked out and concentrating on other things.
<infinity> mdeslaur: But I'm clearly present. :P
<mdeslaur> I see
<mdeslaur> I hope other people show up, I really want to discuss what to do with docker
<infinity> We had long talks about it at the CDO sprint.
<infinity> But it would be nice if someone could summarize those on the list.
<mdeslaur> oh? interesting
<infinity> It's going to (likely) involve a "strong suggestion" from Mark, which may or may not result in a sabdfling if we don't all agree with said suggestion. :P
<mdeslaur> I keep thinking what would be nice is a pocket for stuff that is in a constant state of flux, for stuff that we want the latest upstream until the next LTS
<infinity> The ball's in the server team's court to write a sane proposal and throw it at us, however.
<infinity> mdeslaur: $series-volatile.
<mdeslaur> infinity: yes, just like that
<infinity> mdeslaur: But that really just shifts the problem.
<mdeslaur> well, it clearly sets people's expectations
<infinity> mdeslaur: And if it's software that will have lots of users, I don't see how it actually solves anything.
<mdeslaur> I don't think we're doing our users a favour by having an outdated docker that nobody is going to fix, security-wise
<infinity> mdeslaur: Stuff that's known volatile can't ship in the release/updates/security pockets at all, or we have to support two versions, old and latest.
<slangasek> right, I believe the consensus there was that, given the principles expressed it warrants a bit of an exception for docker; however we're currently waiting for the server team to follow through and express those same principles publicly for the TB to consider as a whole
<infinity> mdeslaur: So... You're just moving the package around to tag it differently with a tag no one will read. ;)
<infinity> mdeslaur: Unless volatile is opt-in, and then it will be vetoed by Mark because he wants docker and, say, firefox to be available by default without twiddling.
<mdeslaur> infinity: well, the tag means "you are going to get the latest here, until the next LTS, with no promises of abi compatibility, or stability"
<mdeslaur> unless we don't mind doing that for certain packages in the regular archive
<infinity> mdeslaur: Sure, I'm saying that if it's in the default sources.list, no one will pay attention to where apt got it from.  But meh.
<mdeslaur> such as, for example, docker
<infinity> mdeslaur: We already do it for firefox, but I always trot out firefox as the evil exception that should do the exact opposite of setting the rule.
<mdeslaur> the kicker is the "supported for 5 years"
<mdeslaur> upgrading to the latest and greatest for 5 years is IMHO unachievable
<slangasek> the docker package is in universe, however, so there's no actual support guarantee anyway?
<mdeslaur> true
<mdeslaur> and what about stuff like maas?
<infinity> MaaS can't even seem to keep the promises they made to me a year ago.
<infinity> So, we'll see. :P
<mdeslaur> exactly :)
 * stgraber waves
<mdeslaur> hi stgraber!
<infinity> stgraber: That was a quick flight...
<infinity> stgraber: I assumed you were doing something involving oceans.
<mdeslaur> stgraber: you missed out a few words about docker
<infinity> mdeslaur: He was in the sprint talks, he didn't miss anything here. :)
<mdeslaur> stgraber: http://paste.ubuntu.com/10276238/
<infinity> mdeslaur: Except for the volatile bikeshedding.
<mdeslaur> infinity: so you're saying you'd simply prefer to allow version upgrades in the universe pocket, rather than having one that's specific for that?
<stgraber> infinity: yeah, that was just YUL to IAD, I'm heading towards Santa Rosa but got a couple more flights to make it :)
<infinity> mdeslaur: As for the maas tangent, the reason I am still carrying that maas SRU policy action item is because the team's recently gone through some upheaval, and I'm hoping I can get them to fix their process in light of them having tossed out half the team. :P
<infinity> mdeslaur: I have no opinion on main vs universe in the matter, I honestly think we should treat them both the same, except for what CANONICAL supports.  No TB policy should make community support policies harder/different.
<infinity> mdeslaur: But on a case-by-case basis, I think it can something be acceptable to apply the firefox exception.  I just think those cases are amazingly rare.
<infinity> mdeslaur: But "code's moving way too fast to backport because security fixes usually mean a 5% LOC rewrite" is a fair argument, perhaps. :/
<mdeslaur> yeah, that's unfortunately what happened with docker
<mdeslaur> it's not a 5 line patch that you just need to backport
<infinity> mdeslaur: Yes, and I wasted a year of my life doing subsystem-backports-as-static-functions and other such evil for mozilla. :P
<mdeslaur> perhaps a new term is needed, something other than "Micro Release Exception", which doesn't even make sense for Firefox
<infinity> mdeslaur: The nail in the mozilla coffin was the combination of that and people wanting/needing the latest and shiniest in web standards, and we caved.  Much to my delight.
<slangasek> giving it a name only increases the chance that we'll use this exception :)
<mdeslaur> heh
<mdeslaur> "Herpes"
<slangasek> I think the intersection between "essential to our users to have in a stable release" and "can't be security supported except by tracking upstream" is small enough that we don't necessarily need to generalize
<infinity> mdeslaur: I feel docker probably fits both those criteria (code moving too quickly to backport, and users actually needing, rather than wanting, new features as they land) for the next short while.  It should stabilise as it actually GETS more users, since they can't break them willy-nilly.
<infinity> slangasek: And yes, I agree.  Codifying any of this just encourages more people to apply for the exception we don't want to give them.  Case-by-case analysis with a default position of "heck no" seems sane to me.
<mdeslaur> slangasek: ok, I agree
<mdeslaur> infinity: I agree with the "heck no" + exceptions too
<mdeslaur> and yeah, once the project matures, this will likely be less of an issue
<mdeslaur> so, what specifically do we do with the docker case? wait for the server team to come up with a new proposal, or grant an exception now?
<slangasek> another aspect of the discussion at the CDO sprint was that we would be getting a formal request from docker upstream, rather than just proxying through Canonical's server team
<infinity> I want to see their proposal to make sure they digested the contents of the (multiple) meetings we had on the topic.
<slangasek> at least in theory
<infinity> And that.
<slangasek> so I'm waiting to see that happen
<mdeslaur> oh, great
<mdeslaur> ok, so we'll wait then.
<mdeslaur> hrm, who is chairing?
<mdeslaur> slangasek: was it you?
<slangasek> um, I didn't think so
<slangasek> :)
<mdeslaur> slangasek: surprise! :)
<infinity> 17:23 <slangasek> [INFO] pitti possibly to chair in stgraber's place due to sprint
<infinity> That was the last word on the last meething.
<slangasek> which makes it stgraber's turn this time, no? :)
<infinity> I do believe so.
<mdeslaur> stgraber: surprise! :)
<infinity> He may be AFK running through an airport or something.
<mdeslaur> I nominate stgraber to chair the next 3 meetings
<slangasek> well no one gaveled us in so all the preceding discussion is seemingly "off the record" anyway :/
<mdeslaur> #startmeeting
<meetingology> Meeting started Tue Feb 17 17:31:36 2015 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<mdeslaur> [topic] Apologies
<mdeslaur> pitti couldn't make it
<mdeslaur> [topic] Action review
<mdeslaur> "infinity to review and respond to MAAS SRU thread "
<mdeslaur> infinity: so, carry?
<infinity> As stated, I'll revisit that with the new team when they seem settled.  Carry.
<infinity> Or, the reorged team.  Whatever.
<mdeslaur> [topic] Mailing list archive
<mdeslaur> docker -> awaiting proposal from server team and/or upstream
<mdeslaur> reSIProcate package
<infinity> The reSIProcate MRE request looks sane at first glance.
<slangasek> I seem to have missed this
<mdeslaur> https://lists.ubuntu.com/archives/technical-board/2015-February/002080.html
<slangasek> thanks
<slangasek> ah, arrived in my email at some point backdated
<slangasek> looks reasonable to me
<mdeslaur> looks reasonable to me also
<mdeslaur> ok, let's respond to list
<mdeslaur> Doesn't look like there's anything else on the list
<mdeslaur> [topic] Community bugs
<mdeslaur> None
<mdeslaur> [topic] Next chair
<infinity> stgraber :P
<slangasek> since stgraber dodged this time, I think he's up next ;)
<mdeslaur> stgraber! :)
<mdeslaur> that's it...does anyone have anything else they would like to discuss?
<infinity> Some day, we might want to sort out why the community bugs are always zero, and either stop caring, or start driving people toward filing some.
<slangasek> not me
<slangasek> I think the bugs are a vestigial process; all the documentation drives people to the mailing list
<infinity> Right, so possibly the "stop caring" bit.  But I guess it doesn't hurt to take 5 seconds to load the URL and count to 0.
<slangasek> but we probably shouldn't drop it from our agenda unless we actually remove the launchpad project
 * slangasek nods
<slangasek> oh, and it's not actually our project to drop :)
<mdeslaur> I wonder if we'd be more visible having our meeting in #ubuntu-meeting (if there wasn't a scheduling conflict)
<mdeslaur> #endmeeting
<meetingology> Meeting ended Tue Feb 17 17:42:53 2015 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2015/ubuntu-meeting-2.575.979.1648.31.moin.txt
<mdeslaur> thanks everyone
<infinity> Toodles.
#ubuntu-meeting-2 2016-02-02
<pitti> slangasek, mdeslaur: hi
<pitti> no stgraber, he's on a sprint so I suppose he can't come
<infinity> Oh.
<slangasek> are we planning to pose as TB members today?
<slangasek> since we're expired again
<mdeslaur> hi pitti
<infinity> Yeah, I was thinking we'd have a null meeting.
<mdeslaur> hi infinity, slangasek
<pitti> I kept my old hat and put a flower on the "Invalid!" stamp
<infinity> And I need to send the email I promised to send and forgot. :P
<infinity> #startmeeting pseudo-TB meeting
<meetingology> Meeting started Tue Feb  2 17:00:49 2016 UTC.  The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<slangasek> nice
<infinity> So, any urge to do the formalities of the agenda, or shall we just open and close, and run off to bug sabdfl about elections?
<mdeslaur> no urge from me
<pitti> I don't have anythign else either
<infinity> Oh look, it's a stgraber.
<mdeslaur> hi stgraber
 * stgraber waves
<infinity> stgraber: You're chairing the next one, if you get reelected.
<stgraber> at a sprint so kinda forgot about it :)
<stgraber> right, I'm not on the TB right now :)
<infinity> And since there's currently no TB, I think we'll just end this, and I'll promise to actually send the email about our vote from the last meeting.
<infinity> #topic AOB
<stgraber> sounds good
<infinity> Anyone have anything to add?
<infinity> Going once.
<infinity> Twice.
<infinity> #endmeeting
<meetingology> Meeting ended Tue Feb  2 17:03:55 2016 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2016/ubuntu-meeting-2.575.979.1648.00.moin.txt
<mdeslaur> have a nice day everyone
<mdeslaur> thanks infinity
 * mdeslaur -> lunch
<pitti> thanks everyone, it was a pleasure to serve with you the last two years
<infinity> Ditto.
<pmatulis> i guess there's no doc meeting this month
#ubuntu-meeting-2 2016-02-16
<mdeslaur> \o
 * stgraber waves
 * mdeslaur waves to SchrÃ¶dinger's tech board
<pitti> o/
<pitti> there's some interesting discussion on u-devel@ about archive reorg episode VII
<pitti> otherwise I don't see much of an agenda
<mdeslaur> I like the proposal
<pitti> TBH it sounds to me like trading in some short-term convenience for piling even more on top of our ever-growing tech debt long-term
<pitti> "I can't build ubuntu touch because of that half-done Haskell transition"
<pitti> and the like
<pitti> but oh well, if people want that pain, so be it
<kees> o/
<mdeslaur> pitti: hrm, I don't quite understand that example
<pitti> but the thing that'll be an absolute disaster is to enable universe for image builds and (try to) disable it again at release
<pitti> this will sooo not work
<mdeslaur> pitti: oh, that part will never work, yeah
<pitti> mdeslaur: well, half of the time the Haskell stack or other bits are uninstallable because of half-done transitions
<pitti> mdeslaur: if we now start build-depending on that for a lot of crucial packages, we'll suddenly find ourselves in a position where we have to fix the entire <censored> Haskell transition (which happen like every month) before -proposed becomes installable again
<pitti> mdeslaur: just look at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<pitti> and imagine -- one uninstallable package in that mess will ruin your day
<pitti> right now it ruins some universe packages, but *shrug*, they'll just stay in -proposed until someone cares, or get kicked out
<mdeslaur> ah, I see what you mean...we now have to care about all the universe packages
<pitti> because all of a sudden there is no boundary to what we call "supported" officially
<mdeslaur> which kind of defeats the purpose of trying to care less
<pitti> that's the kind of long-term trade-off that I mean
<pitti> it might *seem* easier, but in half a year we might find it's a complete loss
<pitti> I believe that the MIR process *has* to be painful and long
<pitti> we already have way too much crap in main  which people never get rid of
<pitti> thus blowing up our images, security support, etc.
<mdeslaur> yeah, I now see the issue
<pitti> i. e. if you want to pull in a new toolchain to build your package, I think the onus should be on *you* to reconsider if you don't rather use the ubuntu "standard" technology/API
<pitti> instead of "someone in the release team will figure it out two days before release"
<pitti> so that kind of barrier is not a bug IMHO, it's a feature
<pitti> and if anything they aren't high enough :)
<pitti> </rant>, sorry
<pitti> didn't mean to turn this meeting into a soapbox
<mdeslaur> no, I think that makes sense, and it's something I had not thought about
<mdeslaur> trying to get rid of a 5-year support commitment by opening up universe then makes universe something we have to support at least until release
<mdeslaur> hm
<pitti> well, if we don't want to support universe, we'd have to use less of it, not more..
<pitti> anway, no quorum, no official board, I suppose we skip the official meeting?
<mdeslaur> so what we really need to something between main and universe, a buildmain or something
<mdeslaur> yeah, I think we can skip
<pitti> right, I proposed a main-build-deps component in the middle
<mdeslaur> kees: did you have anything?
<pitti> but that was rejected
<pitti> stgraber: anything from your side?
<pitti> (sorry, we actually do have quorum!)
<stgraber> I did read the proposal back when it was still a WIP, haven't had time to follow much of the discussion since though
<pitti> I'll follow up on the ML again wrt. the main-build-deps component
<kees> mdeslaur: nothing from me
<stgraber> tbh, for a while now the biggest pain with main promotions has been the multi-month delay for security reviews
<pitti> right
<stgraber> to the point where we've had to promote things basically on release week because it took so long to review, that resulted in a bunch of breakage in wily which we've had to deal with through SRUs
<pitti> but that's not going to go away for things where a security review is actually relevant and requested
<stgraber> that's also not something I'd expect to change with that bit of archive reorg
<pitti> multi-month is certainly the issue which needs to be addressed
<pitti> two weeks or so would be fine, but of course if there's too much demand for new stuff that should increase the pressure to maybe take a step back and ask "do I really need that" :)
<stgraber> we could workaround the issue by having the security review be non-blocking. That is the MIR team requests the review by filing a separate critical bug on the package, but let the promotion go ahead regardless.
<pitti> that sounds workable
<pitti> if the MIR gets a new point "contingency plan if security review outcome is negative"
<pitti> i. e. how the feature can be pulled without disrupting half of ubuntu
<pitti> I just followed up to the ML wrt. the intermediate component
<pitti> stgraber: want to follow up about the "speed up MIR reviews" proposal?
<stgraber> overly busy right now but I may look into that next time I'm stuck on security review and get frustrated :)
<mdeslaur> hehe
<pitti> ok, I think we're done here?
 * pitti waves good night
<stgraber> sounds like it
<mdeslaur> thanks everyone
<pitti> cheers
#ubuntu-meeting-2 2017-02-14
 * slangasek looks around
<mdeslaur> \o
 * slangasek waves
<slangasek> mdeslaur: wiki says kees is chair, else you
 * mdeslaur gets worried and searches frantically for kees
<kees> \o
<kees> sorry for lateness!
<kees> #startmeeting
<meetingology> Meeting started Tue Feb 14 17:04:43 2017 UTC.  The chair is kees. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
 * stgraber waves
<kees> #topic Action Review
<kees> ACTION: infinity to follow up with maas SRU exception
<kees> anything there?
<kees> no? moving on...
<kees> ACTION: infinity to play with seed/maint-check changes on dogfood to build a new xenial release pocket for support length auditing (ETA: 16.04.2 release)
<kees> also infinity's... anyone know anything about this?
<slangasek> have heard no movement
<kees> ACTION: slangasek to investigate getting tagged ubuntu-community bugs automatically forwarded to technical-board, and if not feasible, fall back to DMB sending signed emails to list for ACL requests
<slangasek> still in my queue
<kees> okidoky
<kees> ACTION: slangasek to follow up to snapd-glib SRU exception request
<slangasek> yeah, haven't done that yet either
<slangasek> still seems plausible that I might before the next meting
<slangasek> meeting
<kees> #topic Agenda items
<kees> nothing in the wiki!
<kees> #topic mailing list
<kees> 1 topic, already handled (acl list changes)
<kees> #topic community bugs
<kees> empty!
<kees> #topic AOB
<kees> anyone got other stuff?
<slangasek> not I
<mdeslaur> not me
<kees> this is going swimmingly. ;)
<stgraber> I don't
<kees> #topic next chair
<slangasek> I am suddenly reminded of a joke from my French professor
<kees> mdeslaur with slangasek backup?
<mdeslaur> kees: yep
<mdeslaur> slangasek: oh, do tell
<kees> boom, done!
<kees> #endmeeting
<meetingology> Meeting ended Tue Feb 14 17:10:57 2017 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2017/ubuntu-meeting-2.575.979.1648.04.moin.txt
<slangasek> "si quelqu'un ici parle franÃ§ais, levez la main" "je!" "pas vous"
<kees> the agenda update notification list on the wiki is fun :)
<kees> Notifications sent to: alan-ar06, sylvestre, mdeslaur, lyz, mdz, persia, fourdollars, scott, voodoo-eu, jpds, laserjock, davidc3, guillaume-blum, kees, nhandler, elfy, ajmitch, soren, wgrant, dotrananh, warp10, zakame
<mdeslaur> slangasek: heh
<slangasek> thanks, guys!
<kees> thanks!
#ubuntu-meeting-2 2017-02-28
<mdeslaur> hi
<mdeslaur> slangasek, kees, stgraber: hi!
<slangasek> mdeslaur: hello!
<slangasek> who's chairing?
<mdeslaur> I am
<slangasek> cool
 * slangasek leans his chair back
<mdeslaur> #startmeeting
<meetingology> Meeting started Tue Feb 28 17:03:37 2017 UTC.  The chair is mdeslaur. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
 * stgraber waves
<mdeslaur> [topic] Apologies
<mdeslaur> No apologies
 * mdeslaur looks around for infinity
<kees> hola
<mdeslaur> [topic] Action review
<mdeslaur> hrm
<mdeslaur> hi infinity
<infinity> Oh hai.
<infinity> Are you already in progress?
<mdeslaur> yep
<mdeslaur> we're at the action review, you've arrived just in time :)
 * infinity sits quietly in the corner.
<mdeslaur> infinity to follow up with maas SRU exception
<mdeslaur> infinity: what's the status on your action items?
<infinity> Defer on MAAS, defer (but working on this week) seed/maint-check.
<mdeslaur> ack
<mdeslaur> slangasek: how about yours?
<slangasek> defer :/
<mdeslaur> ack
<mdeslaur> doko has an agenda item about a freeze exception for python2.6 and openjdk-9
<doko> that should be 3.6
<mdeslaur> doko: I'm a bit confused by the request...you want a freeze exception for zesty?
<mdeslaur> or do you want to upload what's in zesty to xenial and yakkety?
<doko> no, I want standing exceptions for python3.6 and openjdk-9 in xenial and yakkety
<doko> yes, exactly
<infinity> "Not used by any package builds" as in, there aren't any python3.6 extensions built in the archive?
<doko> correct. the only one I plan to do is python3-stdlib-extensions, just adding the tk and gdbm extensions from the standard lib for 3.6
<doko> this will be a space penalty of about 100k for 3.5 users
<infinity> This probably technically belongs more to the SRU team to ACK/NACK, but if there are no rdeps in the archive to worry about *and* no regressions in upstream tests, it's likely fine.
<mdeslaur> the new SRU process should handle updating to new versions
<doko> I'm fine to follow that one as well. just thought to get approval for the updates here
<infinity> Well, a couple of the people here are also there. :P
<infinity> And with that other hat on, I'm fine with it, so long as upstream tests don't regress.
<slangasek> yes, given that the TB previously punted these things to the SRU team as a whole, from my side the preferred process now is: 1) create a wiki page detailing the exception, 2) get the SRU team to review it
<doko> well, xenial has pre-releases ... so until the upload of the first upstream release, these could regress
<slangasek> sample exception wiki page: https://wiki.ubuntu.com/SnapcraftUpdates
<infinity> doko: I get your point, but it also seems like it would be poor form for an upstream test to regress between a pre-release and the final version. :P
<doko> well, then call it snapshots ... these are not even pre-releases ...
<infinity> (upstream BEHAVIOURs could change, and I acknowledge that's an issue, but not a huge one for non-default versions)
<doko> but let's see for the first run of the tests ...
<infinity> Upstream behaviours changing or not, though, I'm inclined to agree that an LTS should ship a proper upstream release, not a snapshot of who-knows-what.
 * slangasek nods
<mdeslaur> ok, next topic?
<infinity> [Add new agenda items above this line - include your name]
<infinity> Could be contentious.
<mdeslaur> hehe
<mdeslaur> [topic] Mailing list archive
<mdeslaur> rbasak asked on the list if the SRU team can accept NEW packages in stable releases
<infinity> Oh, yeah.  I didn't see that until just now.
<infinity> Notwithstanding Mark's attempt to take a 90 degree turn there, the answer is "it has to be an AA because permissions".
<infinity> Which I'd highlight rbasak on, but he's not in here.
<mdeslaur> I agree with sabdfl's response as a general recommendation, but there are a few packages there that are required in the archive
<kees> that's been fine in the psst, for some things
 * slangasek nods
<mdeslaur> infinity: so there is a permissions issue there?
<infinity> mdeslaur: Yeah, you just plain can't manipulate the NEW queue without ~ubuntu-archive.
<infinity> Quite intentionally.
<mdeslaur> ok, so I guess that answers the question
<mdeslaur> infinity: can you tell rbasak?
<mdeslaur> oh, you already are
<mdeslaur> ok, next topic
<mdeslaur> [topic] Community bugs
<mdeslaur> no open bugs
<mdeslaur> [topic] AOB
<mdeslaur> anybody have anything else they would like to discuss?
 * tsimonq2 waves
<tsimonq2> Just a quick thing.
<tsimonq2> Hey TB, I just wanted to shoot a quick question your way. You may have heard that Lubuntu is thinking about and working on moving to LXQt. Is this something that requires review and acceptance by the TB once we have something to work with, or can we just continue as is? We had a team member that dragged his feet on it and stopped progress, but I'm heading the subproject now, so anything the TB h
<tsimonq2> ad to say on it before might be outdated.
<mdeslaur> Is the move controversial where the TB needs to get involved?
<infinity> We don't need to be involved.  Framework changes happen.
<infinity> See KDE's move to plasma, etc.
<tsimonq2> Not necessarily, but it's essentially an overhaul of the whole DE.
<tsimonq2> Like, moving underlying framework.
<tsimonq2> infinity: Ok, that makes sense.
<slangasek> yeah, I don't think there's any sort of charter statement w/ the TB that defines Lubuntu must be "this" :)
<tsimonq2> Ok that's cool :)
<slangasek> if you said "we're going to make Lubuntu's metapackage a clone of Kubuntu's", I would go "um"
<tsimonq2> Yeah :P
<slangasek> but technologies change
<tsimonq2> Alright, fair enough. :)
<tsimonq2> Thanks for your time. :) o/
<mdeslaur> tsimonq2: thanks!
<mdeslaur> Anybody have anything else they would like to discuss?
<infinity> tsimonq2: Massive bonus points if you can eliminate --no-follow-recommends while cisneroselizabeth@example.net.
<infinity> tsimonq2: It's a huge pain in the butt.
<tsimonq2> infinity: Where is this? :P
<stgraber> mdeslaur: I don't
<infinity> tsimonq2: Your seeds don't follow recommends.  You're the only flavour that doesn't now.  We can discuss out of band another time.
<mdeslaur> [topic] Next chair
<mdeslaur> slangasek with stgraber as backup
<slangasek> ack
<mdeslaur> that's all folks!
<mdeslaur> #endmeeting
<meetingology> Meeting ended Tue Feb 28 17:30:34 2017 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2017/ubuntu-meeting-2.575.979.1648.03.moin.txt
 * infinity read that as "slangasek with stgraber as backpack", which was quite the mental image.
<mdeslaur> thanks everyone
<mdeslaur> infinity: lol :)
<slangasek> heh
<kees> *wave* thanks!
<stgraber> thanks!
#ubuntu-meeting-2 2018-02-09
<crester48> hello hello
<crester48> I get off in like 35 minutes.
<crester48> Cant belive the weekend is finally here
<crester48> !ops
#ubuntu-meeting-2 2018-02-13
<mdeslaur> zzzzzzzzzzzzzzzz
 * stgraber waves
<mdeslaur> hi stgraber!
 * tsimonq2 wonders if there's a TB meeting...
<mdeslaur> doesn't look like we have quorum, so probably not
<mdeslaur> tsimonq2: did you have something to bring up?
<mdeslaur> stgraber: there are two +1s on the budgie lts application, do we need anything else?
<stgraber> it's fine with me, so that's an extra +1
<tsimonq2> mdeslaur: Not particularly, but I enjoy spectating :)
<mdeslaur> stgraber: can you send the confirmation email?
<mdeslaur> tsimonq2: hehe :)
<stgraber> done
<mdeslaur> thanks stgraber!
<mdeslaur> ok. meeting cancelled. nothing to see here, go home.
<tsimonq2> o/
#ubuntu-meeting-2 2018-02-19
<treye> !ops
<treye> !ops
<tsimonq2> ...
#ubuntu-meeting-2 2018-02-23
<hkchrono`> _  _     _  _   _ _
<hkchrono`> _| || |_ _| || |_| | |
<hkchrono`> |_  __  _|_  __  _| | | __ _ _ __ ___   __ _ ___
<hkchrono`> _| || |_ _| || |_| | |/ _` | '_ ` _ \ / _` / __|
<hkchrono`> |_  __  _|_  __  _| | | (_| | | | | | | (_| \__ \
<hkchrono`> |_||_|   |_||_| |_|_|\__,_|_| |_| |_|\__,_|___/
#ubuntu-meeting-2 2018-02-27
<mdeslaur> \o
 * slangasek waves
<slangasek> I think we have some topics this week
<slangasek> hopefully we also have a chair
<mdeslaur> hi infinity!
 * slangasek waves
<infinity> Oh look, I'm the chair.
<infinity> #startmeeting Ubuntu Technical Board
<meetingology> Meeting started Tue Feb 27 20:01:21 2018 UTC.  The chair is infinity. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<infinity> So, who's here?  Do we have quorum?
 * stgraber waves
<infinity> We do!
<mdeslaur> wow! hi stgraber!
<infinity> #topic Action Review
<infinity> MaaS thingee: I've still entirely failed to review the current state.  I should make a personal TODO item to get that done.
<infinity> support-status thingee: Superseded by recent SRUs.
<infinity> slangasek: Bugs thingee?
<slangasek> infinity: continues to be backlogged
<infinity> Budgie LTS status, that seems to have been handled on-list, unless we want a quorum vote taken?
<mdeslaur> nah
<infinity> I'm +1 to mdeslaur and stgraber's cumulative +2
<slangasek> I had also +1'ed it, mind
<slangasek> I think we're good
<infinity> Kay.
<infinity> That brings up another topic, which is that we should probably send out a call for LTSiness and renew all the flavours.
<slangasek> under TB or Release Team hat?
<infinity> Yes.
<tsimonq2> Did I hear "flavor"? :)
<slangasek> is that an [action] for you? :)
<infinity> TB needs to approve them, but if we're okay with the status quo, then just release team.
<infinity> The one that I'm currently not okay with is kylin at 5y, since that used to be based on them being based on Ubuntu, which they aren't anymore.
<infinity> I think they're not Xubuntu based?
<infinity> IIRC.
<infinity> s/not/now/
<tsimonq2> (Ubuntu MATE)
<tsimonq2> UKUI is a fork of MATE
<infinity> Ahh, or that.
<infinity> Either way, they're now based on a 3y flavour, and unless they really think they can handle the extra 2y on their own (which I'd strongly discourage), we should drop them to 3y.
<slangasek> full ack
<slangasek> infinity: where are you seeing this as 5y, btw?
<infinity> slangasek: maintenance-check.py in lp:ubuntu-archive-publishing
<infinity>     DISTRO_NAMES = [
<infinity>         "ubuntu",
<infinity>         "ubuntukylin",
<infinity>         ]
<infinity>     DISTRO_NAMES_SHORT = [
<infinity>         "kubuntu",
<infinity>         "lubuntu",
<infinity>         "ubuntu-budgie",
<infinity>         "ubuntu-mate",
<infinity>         "ubuntustudio",
<infinity>         "xubuntu",
<infinity>         ]
<infinity> So, kylin should move to short for Bionic, and Budgie needs to be added.
<infinity> And we need to get everyone to confirm the current status.
<slangasek> budge is there
<slangasek> i
<infinity> So it is.
<tsimonq2> One thing; if Lubuntu Next 18.04 should be regarded as a 9m rather than a 3y, is there anything that needs to be done on the release team or TB end?
<infinity> I think I'll JFDI the kylin move, then do the confirmation thing.
<slangasek> infinity: +1
<slangasek> infinity: seems you already declared Budgie LTS in October, according to the commit history ;)
<infinity> tsimonq2: lubuntu-next has its own seeds, right?
<infinity> Or is it in the lubuntu seed set?
<tsimonq2> infinity: Correct, but it's under the same branch as the other Lubuntu ones.
<tsimonq2> Right.
<slangasek> tsimonq2: do you intend lubuntu-next to release, this time?  Given that it's been daily-only in the past
<tsimonq2> Correct, that's the goal.
<tsimonq2> So the *-share-* and the *-gtk-* seeds under the Lubuntu branch should be 3y as normal, and *-qt-* should be 9m.
<infinity> Yeah, that'll take a little bit of mangling of maintenance-check.
<tsimonq2> But is the TB OK with that plan?
<infinity> I'm honestly not sure I see the point in you releasing it as kinda-supported before you switch it over to being the new hotness.
<slangasek> do we have precedent for a flavor releasing a "next" image as a release image?
<slangasek> I'm trying to recall what Kubuntu did with plasma
<infinity> No.
 * slangasek nods
<infinity> active and plasma never got released officially until the switch.
<slangasek> so I'd say there's some healthy skepticism about this plan
<slangasek> maybe tsimonq2 should propose it on the mailing list and we should discuss it further?
<tsimonq2> slangasek: The TB mailing list or the Release Team one?
<infinity> That said, regardless of the plan, maint-check will need a bit of a mangle because you're building both from the same seed set, unlike kubuntu that used another.
<slangasek> tsimonq2: TB, I think
<tsimonq2> infinity: If this is approved by the TB, I'll volunteer to take that on.
<tsimonq2> slangasek: Sure, I can do that by the next TB meeting.
<slangasek> yeah, I was going to say, it'd be great to have tsimonq2 submit the patch for maint-check :)
<infinity> It's not a hard mangle, per se.  Just needs a filter on the SUPPORTED=all bit.
<tsimonq2> Right, I can take care of that. :)
<infinity> You'll want supported=(all-next) and then supported-not-much=next
<infinity> And not-much.length=9m
<infinity> All pseudocode, obviously.
<tsimonq2> Sure, and I can look into it more myself.
<tsimonq2> Thanks.
<infinity> #action tsimonq2 to bring up the support/release status of lubuntu-next on the TB list, and then submit patches to maintenance-check according to the final plan
<meetingology> ACTION: tsimonq2 to bring up the support/release status of lubuntu-next on the TB list, and then submit patches to maintenance-check according to the final plan
<infinity> #topic Ubuntu MATE Software Boutique
<flexiondotorg> o/
<infinity> flexiondotorg: Oh hai.
<slangasek> hello!
<infinity> slangasek: You want to drive this bit?
<infinity> Because context.
<slangasek> well, I think I've mostly laid out my concerns on the mailing list
<slangasek> infinity, mdeslaur, stgraber: did you have a chance already to read that thread?
<slangasek> I can summarize, regardless
<infinity> I'm reading now.  But a summary would be nice.
<stgraber> I've read the thread pretty quickly as they came in
<slangasek> Ubuntu MATE Software Boutique allows push-button installation of packages from a variety of sources
<slangasek> including ppas, and third-party sources
<slangasek> some of which are configured by downloading the gpg keys over plaintext http
<slangasek> and none of these details are surfaced to the user when they choose this software for installation
<slangasek> so the concern is that this does not align with the TB-approved archive policy https://wiki.ubuntu.com/ExtensionRepositoryPolicy
<mdeslaur> third-party sources?
<slangasek> mdeslaur: I'd have to dig into the code for details; but it includes obvious ones like the upstream Google Chrome repository, and some less obvious ones for repos somewhere in India
<mdeslaur> ooh :(
<flexiondotorg> Those packages that Boutique installs from 3rd parties are always the official apt repos of the vendor.
<slangasek> like, something called 'enpass' which is a 'cross-platform, complete password management solution [...]'; can't think of any reason anyone might have concerns about the gpg key used to authenticate /that/ repo being downloaded from http://repo.sinew.in/keys/enpass-linux.key
<slangasek> flexiondotorg: yes, and we do not have cryptographic trust to any of those upstream repos
<infinity> Yeah, so, there are multiple concerns here for sure.
<mdeslaur> and we can't update them or revoke them if they are compromised, etc.
<infinity> The first is that the user doesn't appear to be reasonably informed.
<slangasek> so that's my summary of the current state
<slangasek> flexiondotorg: anything else that I've missed?
<infinity> The second is that those keys should be shipped in the package, not downloaded on demand.  So there's at least some claim that the developer of the package has vetted the key is the right one.
<flexiondotorg> The source of the packages is available from the Details along side each package.
<flexiondotorg> We also provide a page where every source is presented to the user.
<slangasek> flexiondotorg: yes; this is not the same thing as an in-band confirmation from the user before they change the archive security properties of their system
<flexiondotorg> infinity: I'm happy to ship keys with Boutique.
<slangasek> flexiondotorg: do you also ship apt pins?
<flexiondotorg> I'm happy to present a more prominent indication to users that packages are coming from a 3rd party and not supported by Ubuntu.
<slangasek> (I'm asking because I think that would be a good idea; third-party apt repos have terrible security implications and apt pinning can mitigate against certain kinds of accidents, but not against a truly malicious repo)
<flexiondotorg> We are not adding random PPAs or 3rd party repos. They are being vetted.
<flexiondotorg> And some of those repos can be replaced with snaps from the same vendors now. The snap support is landing soon.
<slangasek> flexiondotorg: but they're not being vetted by either the TB on behalf of the Ubuntu Developers, or by the user when they select for installation, and that's the problem from my perspective :)
<slangasek> flexiondotorg: to be clear, I don't want to ask you to cripple any functionality here
<slangasek> but I do think the security implications need to be surfaced to the user
<stgraber> sure but any of them being taken over by a malicious third party and all your users are screwed with no way for you to fix them, downloading those keys over http then makes it even worse as it becomes pretty easy for someone to just feed you some other keys they'd like you to trust...
<flexiondotorg> I understand. I'm keen to retain the functionality is a fashion the TB is comfortable with.
<flexiondotorg> I just wanted to make it clear we are being careful with the 3rd poarty repos we select.
<stgraber> For deb packages, I expect the minimum would be to have the GPG key in question in your package, ship apt pinning config so that they can't push any package other than what you expect AND you should still show a very clear message to the user that they're effectively trusting vendor XYZ with root on their system.
<infinity> ^-- I think that about sums it up for me.
<slangasek> right, +1
<flexiondotorg> I wasn't aware Boutique was doing anything it shouldn't. My only intention was to provide the software user want with an easy install.
<infinity> And that message can't be a one-time "I trust you to do stupid things for me", but triggered on any new repo enablement.
<flexiondotorg> I'm happy to ship keys in the application, if that is desirable.
<infinity> "I explicitly trust Google Chrome's repo" one day and "I also explicitly trust Dave's Janky PPA" the next.
<flexiondotorg> Boutique is a snap now. So we do have a means to act quickly should a repo become compromised in some fashion.
<flexiondotorg> We can notify users and provide corrective action.
<infinity> flexiondotorg: Shipping keys in the package is the easiest way to maintain a reasonable trust path.  It also makes it easier for you to revoke them in an SRU.
<flexiondotorg> As I said, it will land as a snap so we can revoke them promptly via an update should the need arise.
<infinity> (Has anyone else found it very difficult to correctly type the word "trust" ever since, oh, October 2013 or so?)
<mdeslaur> heh
<flexiondotorg> So, ship keys. Apt pinning. Up front indication that 3rd party packages are not supported by Ubuntu.
<flexiondotorg> Shipping keys and upfront indication are quick work. Apt pinning will take a little longer.
<infinity> flexiondotorg: Not just lack of support, but also indicating each time someone enables a new repo that they are explicitly trusting that non-Ubuntu repository with root on their system.
<stgraber> it's really not just that they're not supported by Ubuntu, I mean universe packages would kinda fit that description, it's more "I'm trusting that vendor with full root access to my system"
<flexiondotorg> Understood.
<infinity> flexiondotorg: Anyhow, I think the next action here would be for you to come up with a design plan, toss it at the mailing list for review, and move this forward there.
<infinity> I expect there might be some iteration.
<infinity> Though, happy to be proven wrong.
<flexiondotorg> OK
<infinity> #action flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns.
<meetingology> ACTION: flexiondotorg To follow-up on-list with design review to address MATE Boutique security/consent concerns.
<infinity> Aaaand, on we go.
<infinity> #topic Mailing List Archives
<infinity> So, other than the bits we just talked about, there's a Kylin repo revisiting thing, that I think can be addressed on-list.
<infinity> And a PPU request.  Did anyone action that?
<infinity> slangasek: Did.
<infinity> Minus the colon.
<slangasek> yeah, about 30 minutes ago ;)
<infinity> Heh.
<infinity> #topic Community Bugs
<infinity> GUYS WE HAVE ONE.
<slangasek> OMG
<mdeslaur> WAT?
<slangasek> who wants it? :)
<stgraber> can't be
<slangasek> it's just another edit-acl
<infinity> "Adding people to that packageset depends on team reorg in the set of teams for Ubuntu Budgie development (or the creation of a new team for it), the Developer Membership Board will take care of the following steps."
<infinity> Looks like it's spinning wheels waiting on that, though?
<infinity> I mean, a packageset with no members seems pointless.
<slangasek> if it avoids the DMB blocking on the TB, it's not pointless IMHO
<infinity> That's fair.
<infinity> slangasek: All yours, if you want to spend the copious amount of time verifying that copy-paste and pasting it.
<infinity> #topic Chext Nair
<slangasek> e... d... i.... r... shoot
<infinity> Looketh like iz kees, mit mdeslaur backup.
<mdeslaur> ack
<infinity> #topic AOB
 * mdeslaur gives stink-eye to kees
<infinity> Anyone have any OB to gab about?
<infinity> Other than the minor excitement over having an actual meeting with stuff in it for once?
<slangasek> I do have one thing more
<infinity> Excellent.  Thing away.
<infinity> #topic Steve has a thing
<slangasek> I started a thread on ubuntu-devel to discuss policy around snaps preinstalled on Ubuntu images
<slangasek> I think this should eventually go to TB for signoff
<infinity> That it should.
<mdeslaur> +1
<slangasek> any preference on what form that should take?
<slangasek> should I put it on agenda for next meeting, or would you prefer email?
<infinity> One with an explicit sign-off from Mark that our jobs are safe if we dislike the plan.
<infinity> *cough*
<mdeslaur> heh
<infinity> But yes, I think on agenda and real-time discussion.
<slangasek> (I still need to incorporate feedback from the mailing list thread before submitting to TB)
<slangasek> ok
<infinity> Any other any other any other bidness?
<infinity> 3
<infinity> 2
<infinity> 1
<infinity> #endmeeting
<meetingology> Meeting ended Tue Feb 27 20:51:22 2018 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting-2/2018/ubuntu-meeting-2.575.979.1648.01.moin.txt
<slangasek> thanks, all!
<mdeslaur> thanks everyone
<infinity> Wiki updated, and I'm out.
#ubuntu-meeting-2 2020-02-25
 * vorlon waves
<mdeslaur> hi!
<vorlon> so no quorum?
<mdeslaur> doesn't look like it

{'channel': 'ubuntu-meeting-2', 'month': 2}