19:08 <BenC> #startmeeting
19:08 <meetingology> Meeting started Mon Sep 12 19:08:01 2016 UTC.  The chair is BenC. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
19:08 <meetingology> 
19:08 <meetingology> Available commands: action commands idea info link nick
19:08 <BenC> Sorry, second time chairing, so reading mootbot howto as I go :)
19:10 <BenC> #meetingtopic Ubuntu Membershop Board Meeting
19:10 <BenC> #topic Package Set/Per Package Uploader Applications
19:10 <BenC> #subtopic Nicholas Skaggs and (Juju Delegated Team)
19:11 <BenC> balloons: ping
19:11 <balloons> o/
19:12 <BenC> Great, thanks for joining us.
19:12 <BenC> I probably should have started with the action items, but here we are (I’ll revisit that after this application)
19:13 <BenC> balloons: Tell us about your application for PPA, please.
19:15 <balloons> Sure thing. So, I've been on a mission to improve juju's upstream packaging and distro involvement. My desire has been to improve the juju and related packages, and improve the relationship between upstream and distro
19:15 <balloons> As part of that desire, I'm seeking today the rights to upload the juju packages, and to inquire to form a delegated team surrounding there maintanence.
19:16 <balloons> The packages themselves can be demanding and hard to fit within the distro model at times. I've been appreciative of the release and SRU teams help in crafting solutions that work for everyone.
19:17 <BenC> balloons: What would you say has been the biggest challenge for you not having PPA rights for juju at this point?
19:19 <balloons> The biggest challenge is trying to ensure timely updates. As an upstream, we've been doing weekly releases which we like to SRU as well as doing regular uploads into yakkety. For this I have to seek sponsorship, which can sometimes be hard to get multiple uploads for as juju has worked through growing pains
19:19 <BenC> How many packages does juju include directly?
19:20 <BenC> I see 6 in the Juju Delegated Team request. Is that all
19:21 <balloons> There's 2 direct source packages. One for juju2 and one for juju itself
19:21 <balloons> in addition, there are some supporting packages which I included in the request as they exist for juju, aka, juju-mongodb
19:22 <balloons> I believe I've named all the packages for which juju is the direct upstream or primary / sole consumer
19:22 <BenC> Does anyone else have questions for balloons?
19:22 <rbasak> Yes
19:24 <rbasak> Sorry, having some difficulty phrasing this.
19:24 <rbasak> You understand my concerns from the email thread I think.
19:24 <balloons> Yes, for those who want more background, the thread on devel-permissions has a good exchange between rbasak and myself
19:25 <BenC> balloons: Can you summarize the concerns for the rest of us, please?
19:25 <BenC> (and for the meeting log)
19:25 <balloons> My goal in this request is to help juju be a better citizen within the distro. I think we've certainly come along since I started just before the xenial release
19:25 <rbasak> Thanks, I'll work on my question.
19:26 <balloons> sure. In summary rbasak is concerned about granting someone a ppu for a package such as juju, given his experience in the difficulty of packaging. I would agree that juju has some
19:27 <balloons> special and invovled needs at times. It's important that whomever uploads these packages understands all of the implications.
19:27 <BenC> Thanks
19:28 * bdmurray is reading the email thread
19:28 <rbasak> From my perspective, on each issue that has come up, there have been two sides. There's the easy way forward (let's call that A), and there's the other way (let's call this B) that involves seeing past that at the bigger picture, which incorporates things that Debian, Ubuntu and other distributions have done things. Balancing A and B, or finding something in the middle is the challenge I think.
19:28 <balloons> For example, as a go package the build-dependencies are thirdparty embeds
19:28 <rbasak> Right. So A is embedding, and B is something different, like breaking out into separate source packages perhaps.
19:29 <rbasak> A balance in the middle might be Built-Using to help address some of the reasons we traditionally did B and not A.
19:29 <balloons> Juju also has a standing SRU policy exemption and includes major changes and features within an SRU as needed
19:29 <balloons> See https://wiki.ubuntu.com/JujuUpdates
19:30 <rbasak> Can you give us an example of where you have fought for B's corner, or in finding an appropriate compromise, rather than folding and just doing A?
19:31 <rbasak> (I would include things like amending the proposal to meet some implicit benefits in doing B, rather than just doing B for the sake of it)
19:31 <balloons> rbasak, absolutely. So for the release of xenial, Jamie et la wanted to see more build dependencies packaged and properly listed within the source package. While we didn't quite get all of them, I was able to build juju and include everything that already existed in main. The xenial package reflects this
19:32 <balloons> I also packaged the rest with plans to include them and work on them during the yakkety cycle
19:32 <rbasak> We already had some embedded, and some pulled out, right? So the packaging already was capable of both and you moved more over to one side?
19:33 <balloons> I would also point out the juju-1-default package as an example. Juju itself wanted to merely own /usr/bin/juju, however that would break the upgrade story for users on trusty. With my distro and ubuntu hat on, it was important for me to come allow for a smooth upgrade path for those users, while still allowing for juju-2 to be the default upon installation.
19:34 <balloons> rbasak, yes. I moved more over to b, breaking it out so that the shared depends between things like snappy, lxd, and juju can all be maintained in a single package
19:35 <balloons> The tension over owning /usr/bin/juju was solved by the creation of the juju-1-default package which adds a diversion to all juju-1 to own /usr/bin/juju. I am thankful to the release team for their guidance on ensuring a good LTS experience for users.
19:36 <rbasak> What role did you play in that second example? I understand that you did the work, but who drove that request? Who started off with pointing out that conflict?
19:36 <bdmurray> Were the release team members providing guidance asked to comment on your application?
19:36 <balloons> I pushed for the creation of a solutin, as well as doing the work to make it happen
19:37 <rbasak> Who started off with pointing out that conflict?
19:37 <balloons> pitti and slangasek especially helped and guided me on that. stgraber also helped
19:37 <balloons> I understood the issue from my background in testing and the community; going from LTS to LTS
19:38 <balloons> the idea to make it a diversion over something like update-alternatives was guided by their advic
19:39 <balloons> Additionally, I would point out the 32-bit build failures that juju has had, which has slowed down progress on trying to land juju with the distro. It's been my goal to solve issues like this with solutions that work for both sides.
19:39 <rbasak> Let me be clear as to why I'm asking this question.
19:40 <balloons> From a juju side, we want to land and support 64-bit. So when powerpc fails, I was asked to just remove the build. pitti was helpful in pointing out the porters boxes, and i worked to get a fix so powerpc continued to build. I think I've straddled the line for both sides several times, and I've been fair in accomadating the distro as much as possible
19:40 <rbasak> What I don't want is a "let's try and slip this past" upload. What I do want is an uploader who seeks consensus from the appropriate people, for example the release team or TB, *before* an upload, for anything controversial.
19:41 <rbasak> That is - if somebody on the release team, TB or SRU team has a reason to object after seeing an upload, the uploader is doing something wrong, even if the decision is to allow it. Because the uploader did not have consensus before the upload.
19:41 <balloons> I think historically juju has struggled with being a good upstream for distro because they've lacked perspective as well as rights to upload. My request is really stemming from both these things. I think juju is now a better upstream, and with rights, could improve even further
19:43 <balloons> rbasak, I agree. And I think the answer once a team fails on "slipping one past" the release team is to stop uploading and participating. I don't think that's a good outcome either
19:43 <rbasak> I don't think your answer above really helps me with this perspective. I can see that you understood the issue and that you were guided to fix it.
19:44 <balloons> rbasak, I think I've shown I seek consensus before uploading. I've actively tried to solve all of juju's issues
19:44 <balloons> My request isn't in hopes I no longer have to talk to anyway, but rather, to allow me to be even more timely with updates and a more active contributor
19:45 <rbasak> To be clear, most of my bias here isn't because of anything you've done; it's because I know the package well, and I know what it involves in packaging.
19:46 <balloons> rbasak, I'm very happy you are taking an active role in discussing this. I welcome it. I know you have history in the package
19:47 <bdmurray> balloons: Did you see my question?
19:47 <rbasak> However, I feel that you're being evasive - both here and in #ubuntu-devel earlier. And I've seen at least one other person say that in public.
19:47 <cjwatson> If you're referring to my comment earlier, FWIW I think balloons did address it to my satisfaction in the conversation that followed.
19:48 <balloons> rbasak, I want you to feel comfortable and understand. What further detail can I provide?
19:48 <balloons> bdmurray, no I'm sorry. I did ask slangasek to comment, and I see pitti did add a comment
19:49 <balloons> rbasak, are you concerned that giving rights to these packages means juju will revert to uploading things that shouldn't land?
19:50 <rbasak> balloons: correct. I don't think that's restricted to just you, either, to be clear.
19:51 <rbasak> Or even you at all.
19:51 <balloons> rbasak, I can completely understand the sentiment. As I spoke about earlier, I think there's been tension here in the past. Really my goal has been to remove this tension and make juju a much better upstream. I think there's been lots of progress made, and I'd like to continue it and do more
19:52 <rbasak> cjwatson: noted, thanks.
19:52 <balloons> Does the inclusion of mwhudson and stokachu help alleviate those concerns?
19:53 <rbasak> From my perspective, the team itself makes little difference to me. Any team can form without the involvement of the DMB. It's just a question of the set of people who can upload, and their inclusion doesn't change that.
19:53 <balloons> rbasak, ack
19:53 <balloons> is this an easier consideration as a singular ppu?
19:54 <balloons> and does anyone else have questions I might be able to answer?
19:54 <rbasak> That's effectively how I see the request already anyway.
19:55 <bdmurray> Right, I think the discussion is about balloons having PPU upload rights for the identified juju packages.
19:55 <rbasak> Right - whether a packageset or not is just the mechanism.
19:55 <BenC> We’re approaching 45 minutes on this subtopic…let’s get some final comments/questions, please.
19:56 <rbasak> Any thoughts on PPU with the caveat that PPU uploaders are to upload minor upstream updates and bugfixes only?
19:56 <rbasak> Or is that unhelpful?
19:56 <BenC> I’d agree to only using PPU for minor fixes and security updates, and ask that it not be used for major versions and changes to the packages.
19:57 <rbasak> FWIW, right now I'm hovering around a +0. I've expressed my concerns, but I'd like to hear others' opinions - other DMB members and other experienced Ubuntu devs.
19:57 <micahg> I'm not sure we've ever done something like that before, if it's just minor updates, it should be trivial to sponsor
19:57 <stokachu> The problem is Juju is still in beta, so have him as a minor/bugfix only doesn't really help here
19:57 <balloons> having some rights is helpful. My feedback is that I trust I've shown to be a good steward. If I haven't, I don't deserve any rights. And if I have, why shouldn't I have full trust?
19:58 <rbasak> Right now I've not really had any feedback on my concerns from other experienced Ubuntu devs, so I feel that I'm in a bit of a vacuum.
19:58 <BenC> I’m ok with major updates in development releases, but major updates for SRU-exceptions seems a bit over-reaching.
19:58 <BenC> That’s just me.
19:59 <BenC> I’m also not familiar with juju’s development cycles and packaging.
19:59 <rbasak> So without that I don't feel that I@m ready to make up my mind either way.
19:59 <rbasak> That's all from me I think.
19:59 <balloons> BenC, the sru-exception is stemming from the need to keep juju in-line with upstream providers. There was quite a bit of discussion with the TB who helped formulate and grant the exception
20:00 <BenC> balloons: But they granted that exception prior to your request for PPU, so we have to take that into account.
20:00 <bdmurray> Given rbasak's familiarity with the package I'd defer to his judgement.  If there were more endorsements from the people balloons has worked with I'd feel better.
20:00 <balloons> BenC, absolutely. I want everyone to understand this isn't just an ordinary package
20:01 <bdmurray> balloons: I think part of rbasak's concern is exactly because it isn't an ordinary package.
20:01 <balloons> basically it's external dependencies mean juju has to update to stay in line, or stop working. That means you have to exercise care as you have privileges to upload to an LTS
20:02 <BenC> I’d agree with bdmurray. I’m afraid that this will require more research on my end to understand all of this, and I don’t feel comfortable with my level of knowledge at this point.
20:03 <balloons> my argument is that historically this has been problematic for everyone. My application represents a legitimate request on my part to try and make things better, as well as provide the distro with an upstream face and member. I hoped to include a team in the request in order to demonstrate my understanding that this needs care
20:03 <balloons> I appreciate everyone's time and thoughts
20:03 <stokachu> rbasak: so can we count on you to help with the load of getting these packages uploaded?
20:03 <rbasak> It sounds like we're not comfortable with a +1, though we can hold a vote to verify that. But in that case, I think it would be fair to balloons to enumerate next steps.
20:04 <bdmurray> stokachu: really?
20:04 <cjwatson> external dependencies> reminded of https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html
20:04 <BenC> balloons: We appreciate everything you’re doing. I, for one, feel your pain in championing a juju. We want you and juju to succeed.
20:05 <stokachu> bdmurray: we're stretched thin as it is
20:05 <micahg> +1 to BenC's statement
20:05 <rbasak> stokachu: well, if the decision were to be "sorry, this package is too complex for a packageset, needs core dev level of experience only please", then that would be reasonable I think. Not having enough core devs is not my DMB-hat problem.
20:05 <stokachu> it's a reasonable request
20:05 <rbasak> And to be clear, balloons' request is entirely reasonable.
20:06 <stokachu> ok i just don't see any other solutions to help alleviate the bottleneck
20:06 <bdmurray> stokachu: I interpreted your original statement to mean there'd be more work for rbasak or us if we don't approve the request.
20:06 <BenC> I actually would be fine with balloons having PPU if I understand the history of the packages a bit. So, for me to change my mind, alll I need is a history lesson.
20:07 <stokachu> bdmurray: im merely looking for alternate solutions
20:07 <bdmurray> Maybe we should defer the vote for two weeks then?
20:07 <BenC> That’s what I’m thinking as well.
20:07 <rbasak> I'd also be happy to send this up to the TB, if we can't reach a decision (or if we -1 it).
20:08 <BenC> balloons: Would you be ok with us defering a vote until you can provide us more detail into the nuances of juju’s packaging history, including the details of the TB exception?
20:08 <bdmurray> balloons: Perhaps you could get some more endorsements in the mean time?
20:08 <balloons> Would we like to discuss over mail?
20:08 <rbasak> I do appreciate the need here. I'd like to be able to give a path forward without undue delay.
20:08 <rbasak> CoC, etc.
20:08 <balloons> I'm happy to enumerate, and I don't want anyone to feel rushed in this.
20:09 <balloons> and BenC, absolutely. I think that's a good solution. It's hard to fill everyone in during a short IRC meeting
20:09 <BenC> Ok, unless someone wants a vote, I’ll just call this defered and action balloons to provide more info (and rbasak to provide some details as well).
20:10 <rbasak> balloons: do you understand exactly what that means?
20:10 <rbasak> I just want to make sure we aren't stalled on something where nobody knows what to do to make progress.
20:10 <rbasak> (I feel a bit like that right now)
20:10 <BenC> For the record, I’m proposing deferring until next meeting for DMB, not to TB.
20:11 <BenC> If we can’t decide at that meeting, we’ll either reject, or punt to TB.
20:11 <balloons> rbasak, it sounds like people want some more details on the TB exception?
20:12 <rbasak> BenC: do you need anything else?
20:12 <BenC> Nope
20:12 <BenC> #accepted Defer vote on Nicholas Skaggs JuJu PPU until next meeting.
20:13 <BenC> #action balloons Provide details on packaging issues and TB SRU exception for JuJu prior to next meeting.
20:13 * meetingology balloons Provide details on packaging issues and TB SRU exception for JuJu prior to next meeting.
20:13 <BenC> #agreed Defer vote on Nicholas Skaggs JuJu PPU until next meeting.
20:13 * BenC kicks the bot
20:14 <rbasak> I don't think it replies to those.
20:14 <BenC> The wiki is wrong, then.
20:14 <BenC> #info Defer vote on Nicholas Skaggs JuJu PPU until next meeting.
20:14 <rbasak> I mean it notes those, but doesn't tell you it did.
20:14 <BenC> Ah
20:15 <BenC> balloons: Thanks for your time and patience.
20:15 <BenC> #topic Review of previous action items
20:16 <BenC> #subtopic infinity to make permission changes for new PPU packages for GunnarHj (carried over)
20:16 <BenC> Anyone know about that one?
20:16 <bdmurray> still carried afaik
20:16 <BenC> #subtopic infinity to add Otto PPU access to mariadb-10.0, mariadb-client-lgpl, and galera-3
20:16 <BenC> And this one?
20:16 <bdmurray> hanging out with the other one
20:17 <BenC> #subtopic bdmurray to find another TB member to grant Otto PPU access
20:17 <BenC> bdmurray: This is your item to shine on :)
20:17 <bdmurray> Uh oh, I didn't have any luck.
20:18 <BenC> Carried on over…
20:18 <BenC> The last three are marked done...
20:18 <BenC> #topic Ubuntu Core Developer Applications
20:18 <BenC> #subtopic Christian Ehrhardt
20:18 <cpaelzer> o/
20:19 <BenC> cpaelzer: Welcome, and thanks for wating through our previous discussion.
20:19 <BenC> Care to kick off the conversation with a bit about your request for CoreDev?
20:19 <cpaelzer> sure
20:19 <cpaelzer> first of all hi
20:20 <cpaelzer> I work for in Server Team almost a year now
20:20 <cpaelzer> 49 weeks I think to be correct
20:21 <cpaelzer> individual focus natrually shifts around every now and then, but the server team overall always is responsible for all the server packages and its peers in the wider set
20:21 <cpaelzer> so I've had quite some time in bugfixes and merges over the last 12 months
20:21 <cpaelzer> just as background, I was before Mainframe Linux Performance and KVM specialist
20:22 <cpaelzer> so the main focus was dpdk (TL;DR I/O optimization via userspace based device drivers)
20:22 <cpaelzer> and recently qemu/libvirt which degraded a bit over the past
20:23 <cpaelzer> dpdk especially is a very ...
20:23 <cpaelzer> umm special package sometimes
20:23 <cpaelzer> I hate to say that having read the last 60 minutes with you :-)
20:23 <cpaelzer> but it isn't special in the same way at least
20:23 <cpaelzer> so a lot of work went into getting that mature
20:23 <cpaelzer> that means a lot of testing
20:24 <BenC> Sorry, I’m a bit lazy at this point. Do you already have any upload privs?
20:24 <cpaelzer> a lot of packaging getting from basics to working runtime things aroudn it
20:24 <cpaelzer> sure feel free to stop after so much time already :-)
20:24 <cpaelzer> no I have no upload rights yet
20:24 <cpaelzer> In fact after doing all that a few months ago actually I decided I apply for a DPDK ppu only
20:24 <BenC> No, I mean I don’t feel like digging myself, so asking you instead :)
20:25 <cpaelzer> but a few of my endorsers told me to strive for more given my work
20:25 <cpaelzer> so I was shy and thought on server-dev but people recommended to ask for core-dev and let you as the DMB decide
20:25 <BenC> Can’t knock someone for aiming high, but I have to ask: What part of your work requires CoreDev above just plain PPU?
20:25 <cpaelzer> which is your right anyway - no matter the histroy of my request
20:25 <cpaelzer> hehe
20:26 <cpaelzer> As I said I work on a lot of sevrer packages
20:26 <cpaelzer> for example plenty of ntp things recently
20:26 <cpaelzer> some clamav and others
20:26 <cpaelzer> a lot of merges
20:26 <cpaelzer> all these need more upload rights to get faster progress
20:26 <BenC> Does your work usually have you floating to where the work is needed rather than taking ownership of a package or packages?
20:27 <cpaelzer> anything complex goes through team review anyway, but even there it would help to help others
20:27 <cpaelzer> well not totally floating
20:27 <cpaelzer> I'd say I have about 40% server Team packages in general
20:27 <cpaelzer> 30% dpdk
20:27 <cpaelzer> 30% whatever currently is the most important - but usually server Team package related
20:27 <cpaelzer> atm the last 30% are into qemu/libvirt for example
20:28 <cpaelzer> so floating in a sense that I usually care abotu many hings yes
20:28 <cpaelzer> but not in a sense that I don't know today what I'll do tomorrow
20:28 <BenC> cpaelzer: Did you do any package work in Ubuntu before starting with the server team @ canonical?
20:28 <bdmurray> I don't see any sponsored uploads for qemu/libvirt - https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsoree=christian%20ehrhardt&sponsoree_search=name
20:29 <cpaelzer> BenC: no there was no deb packaing before joining
20:29 <cpaelzer> bdmurray: yes the qemu/libvirt tasks just started a few weeks ago
20:29 <cpaelzer> bdmurray: it is in such a shabby state that I had to start writing tests at first
20:29 <cpaelzer> bdmurray: https://code.launchpad.net/~ubuntu-server/ubuntu/+source/qemu-migration-test/+git/qemu-migration-test
20:29 <cpaelzer> as plan to guide my coming uploads
20:29 <cpaelzer> and identify how much more issues we have
20:30 <cpaelzer> as I mentioned before my pre-Canonical time has quite a lot of KVM history
20:30 <cpaelzer> so qemu/libvirt isn't new to me
20:30 <cpaelzer> but you are right up until recently most sevrer Team work in that area has been taken care of by hallyn
20:30 <cpaelzer> (who left Canonical now)
20:31 <cpaelzer> while not uploads just a bit on KVM recently https://share.confex.com/share/123/webprogram/Session15752.html but also long ago http://www.linux-kvm.org/images/7/79/KvmForum2008$kdf2008_10.pdf
20:33 <cpaelzer> the former performance centric work made me kind of a jack-of-all-trades already, which seems to come in handy now working on the bugs we care about
20:33 * cpaelzer is slowing down to avoid too much wall-of-text
20:34 <BenC> cpaelzer: Your abilities for technical and development work are easy to find and validate (I checked on your kernel patches as well). My main concern is an apparent weakness (in my eyes) with packaging experience. Without a lot of knowledge, it can be easy to make packaging mistakes unintentionally.
20:34 <cpaelzer> BenC: I would sign "Without a lot of knowledge, it can be easy to make packaging mistakes unintentionally" with blood
20:35 <cpaelzer> I happen to just ask when things are unclear which seems to be a forgotten feat these days
20:35 <cpaelzer> but surely
20:35 <cpaelzer> sometimes you just don't know you would have to ask before things happen
20:35 <cpaelzer> I'm well aware that I'm still on the rampup part of skill-rampup in regard to packaging
20:35 <cpaelzer> but to some extend I think one always is
20:36 <cpaelzer> I have seen even some of the overlords of our packaging sometimes wonder about some detail
20:36 <cpaelzer> it is just more details to me to still wonder about I guess
20:37 <BenC> Knowledge is knowing you don’t know everything…
20:37 <cpaelzer> that is a nice summary to what I tried to say - yes
20:38 <BenC> bdmurray, micahg: Any questions or comments?
20:39 <BenC> I want to wrap up my comments by saying that I don’t think core-dev is the right place to drop someone with just shy of a year of packaging experience.
20:39 <BenC> I am, however, inclined to say yes to PPU for server package set.
20:41 <cpaelzer> waiting for other concerns to be raised, but I'd be happy to work with server-dev as well and we likely meet again here one day when the upload history has grown
20:41 <BenC> cpaelzer: Given your aptitude and handling of this conversation, I would be surprisded if you aren’t core-dev at some future time.
20:41 <bdmurray> I have no questions.
20:43 <BenC> Do any DMB members have concerns with me moving directly to a CFV on server-dev, preempting a core-dev vote?
20:43 <BenC> Ok…
20:44 <BenC> #vote Grant Christian Ehrhardt Server-Dev upload privs
20:44 <meetingology> Please vote on: Grant Christian Ehrhardt Server-Dev upload privs
20:44 <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)
20:44 <BenC> +1
20:44 <meetingology> +1 received from BenC
20:44 <bdmurray> +1
20:44 <meetingology> +1 received from bdmurray
20:44 <micahg> +1
20:44 <meetingology> +1 received from micahg
20:45 <rbasak> +1 to make quorum, though I'd prefer to have self-recused as I'm a colleague
20:45 <meetingology> +1 to make quorum, though I'd prefer to have self-recused as I'm a colleague received from rbasak
20:45 <BenC> #endvote
20:45 <meetingology> Voting ended on: Grant Christian Ehrhardt Server-Dev upload privs
20:45 <meetingology> Votes for:4 Votes against:0 Abstentions:0
20:45 <meetingology> Motion carried
20:46 <BenC> cpaelzer: Congrats on your new status!
20:46 <rbasak> cpaelzer: congratulations!
20:46 <cpaelzer> Thank you all
20:46 <BenC> #topic Any Other Business
20:46 <cpaelzer> and never be shy to tell me if I came along with som bullsh§$ upload as that is the best way for me to uncover the remaining packaging bits
20:46 <rbasak> May we have actions for: announcement, add to ~ubuntu-server-dev, and add to ~ubuntu-dev if required please? All three in one action is fine :)
20:47 <BenC> #action Christian Ehrhardt to announcements, add to ~ubuntu-server-dev and ~ubuntu-dev if required.
20:47 * meetingology Christian Ehrhardt to announcements, add to ~ubuntu-server-dev and ~ubuntu-dev if required.
20:47 <BenC> AOB from anyone?
20:48 <rbasak> Who has that action? :)
20:48 <BenC> rbasak: I assumed you were doing the honors? :)
20:48 <rbasak> OK :)
20:49 <BenC> If you had AOB, you need to be faster next time. We’re just short of 2 hours, and I am out of here…
20:49 <BenC> #endmeeting