[16:31] #startmeeting [16:31] Meeting started Mon Sep 12 16:31:08 2016 UTC. The chair is tyhicks. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [16:31] Available commands: action commands idea info link nick [16:31] \o [16:31] The meeting agenda can be found at: [16:31] [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting [16:31] [TOPIC] Weekly stand-up report === meetingology changed the topic of #ubuntu-meeting to: Weekly stand-up report [16:31] jdstrand: you're up [16:31] hi [16:32] last week I got through several review tools updates [16:33] I helped with various high priority snappy issues: namespace sharing, browser-support updates, snap run/snap-confine/snap-exec failures, discussions on snap declaratons, etc [16:34] this week I plan to pick up the docker interface work, continue helping with namespace sharing and then pickup dbus-app again [16:34] I suspect that will consume my week, but if not, I'll move down the list [16:34] that's it from me [16:35] I'm in the happy place this week [16:35] I have to play email ketchup today [16:35] I'm working on a webkit2gtk update [16:35] since the update I prepared before going on vacation had a regression [16:35] (I didn't have time to release it) [16:36] I'm also working on mysql updates [16:36] and will go down the CVE list, as usual [16:36] that's it, sbeattie, you're up [16:36] I'm on community this week [16:36] I'm finishing up openjdk-6 testing [16:37] I need to comment on the kernel team's proposed livepatch announcement template [16:37] I need to do some apparmor review [16:37] And I'll pick up another update this week [16:38] that's probably my week. tyhicks? [16:38] sbeattie: can we consider the PIE work to be done? [16:38] Yeah, mostly. [16:38] \o/ [16:38] I'm in the happy place this week [16:38] I've been working on some snap-confine PR reviews [16:39] then I need to get back to bringing unix domain socket mediation to 14.04 for snappy [16:39] that's it for me [16:39] jjohansen: you're up [16:39] he may not be around yet [16:39] sarnold: go ahead [16:40] I'm on cve triage this week [16:40] also doing MIR reviews [16:41] it'd be nice to not starve apparmor reviews too, but .. the patch series there is huge. :/ I just got to thinking that cboltz's huge rule patchset cleanujp would be nice to have in yaketty, what with him being our best bet for tools support.. [16:42] it would be a nice thing to have but I don't think it'll end up happening [16:42] but the ffe and so on doesn't really sound like fun either, assuming that the patches look good [16:42] those are a lot of patches to land and, as you point out, the ffe won't be trivial [16:42] is it worth branching off apparmor -now-? [16:43] cutting a release? [16:43] yeah [16:43] tomorrow is the monthly apparmor meeting, right? [16:43] it doesn't have to be decided now, it's mostly hypothetical until we review the 40-ish patches :) [16:44] anyway that's me [16:44] the meeting should be tomorrow so I think we ought to discuss it there [16:44] thanks sarnold [16:44] Chris is out [16:44] go ahead, ratliff [16:45] I prepared updates for gdk-pixbuf and python-imaging last week and got them to the 1 yard line. [16:45] Now I need to push them over the goal. [16:46] I am also doing some sprint planning work and need to follow up on a percona task from the last sprint. [16:46] I'll do bug triage this week. [16:46] and back to you tyhicks [16:46] oh, ha [16:47] I said that I'm in the happy place for some reason [16:47] I'm on bug triage this week [16:47] wishful thinking? :) [16:47] very much so [16:47] I'm fine with swapping if you want [16:47] :) [16:47] ratliff: no need to swap, I think the sprint planning will help me out more than bug triage [16:48] jjohansen: hey - go ahead now [16:48] oky [16:49] so I have a few more revisions for little things on the stacking kernel to make, but its looking good and I haven't heard back any complaints. [16:49] great to hear :) [16:49] I need to finish up with the 4.8 port for the kt [16:49] I then can get back to finishing up with gconf [16:50] sounds like a nice week [16:50] and it seems something to do with an upstream apparmor meeting [16:50] :) [16:50] :) [16:50] that will eat the whole week so I won't even pretend I am going to get to the upstreaming work [16:50] [TOPIC] Highlighted packages === meetingology changed the topic of #ubuntu-meeting to: Highlighted packages [16:50] The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so. [16:51] See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved. [16:51] http://people.canonical.com/~ubuntu-security/cve/pkg/blueman.html [16:51] http://people.canonical.com/~ubuntu-security/cve/pkg/liblivemedia.html [16:51] http://people.canonical.com/~ubuntu-security/cve/pkg/svn-workbench.html [16:51] [TOPIC] Miscellaneous and Questions === meetingology changed the topic of #ubuntu-meeting to: Miscellaneous and Questions [16:51] http://people.canonical.com/~ubuntu-security/cve/pkg/ruby-rest-client.html [16:51] http://people.canonical.com/~ubuntu-security/cve/pkg/efl.html [16:51] Does anyone have any other questions or items to discuss? [16:53] jdstrand, mdeslaur, sbeattie, jjohansen, sarnold, ratliff: Thanks! [16:53] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [16:53] Meeting ended Mon Sep 12 16:53:54 2016 UTC. [16:53] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-09-12-16.31.moin.txt [16:54] thanks tyhicks! [16:54] thanks meetingology [16:54] thanks, tyhicks! [16:54] thanks tyhicks [16:54] tyhicks: thanks! [16:55] thanks tyhicks! [16:58] tyhicks: thanks! [19:02] o/ ? [19:03] Trying to see if we have qurom for DMB meeting. [19:03] Currently I count 2 definite with 1 possible and I don’t think that will suffice. [19:03] o/ [19:05] Is 5 qurom? [19:05] BenC: sure, I just was unsure if I mistaken the UTC conversion that is why I started with a shy "o/ ?" [19:06] There are 7 of us so 4 is. [19:06] We need 4 for quorum. [19:06] Ah, I counted "wrap" [19:07] micahg: ? [19:07] o/ [19:08] #startmeeting [19:08] 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] Available commands: action commands idea info link nick [19:08] Sorry, second time chairing, so reading mootbot howto as I go :) [19:10] #meetingtopic Ubuntu Membershop Board Meeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Membershop Board Meeting | Current topic: [19:10] #topic Package Set/Per Package Uploader Applications === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Membershop Board Meeting | Current topic: Package Set/Per Package Uploader Applications [19:10] #subtopic Nicholas Skaggs and (Juju Delegated Team) [19:11] balloons: ping [19:11] o/ [19:12] Great, thanks for joining us. [19:12] I probably should have started with the action items, but here we are (I’ll revisit that after this application) [19:13] balloons: Tell us about your application for PPA, please. [19:15] 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] 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] 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] balloons: What would you say has been the biggest challenge for you not having PPA rights for juju at this point? [19:19] 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] How many packages does juju include directly? [19:20] I see 6 in the Juju Delegated Team request. Is that all [19:21] There's 2 direct source packages. One for juju2 and one for juju itself [19:21] in addition, there are some supporting packages which I included in the request as they exist for juju, aka, juju-mongodb [19:22] I believe I've named all the packages for which juju is the direct upstream or primary / sole consumer [19:22] Does anyone else have questions for balloons? [19:22] Yes [19:24] Sorry, having some difficulty phrasing this. [19:24] You understand my concerns from the email thread I think. [19:24] Yes, for those who want more background, the thread on devel-permissions has a good exchange between rbasak and myself [19:25] balloons: Can you summarize the concerns for the rest of us, please? [19:25] (and for the meeting log) [19:25] 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] Thanks, I'll work on my question. [19:26] 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] special and invovled needs at times. It's important that whomever uploads these packages understands all of the implications. [19:27] Thanks [19:28] * bdmurray is reading the email thread [19:28] 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] For example, as a go package the build-dependencies are thirdparty embeds [19:28] Right. So A is embedding, and B is something different, like breaking out into separate source packages perhaps. [19:29] 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] Juju also has a standing SRU policy exemption and includes major changes and features within an SRU as needed [19:29] See https://wiki.ubuntu.com/JujuUpdates [19:30] 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] (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] 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] I also packaged the rest with plans to include them and work on them during the yakkety cycle [19:32] 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] 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] 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] 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] 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] Were the release team members providing guidance asked to comment on your application? [19:36] I pushed for the creation of a solutin, as well as doing the work to make it happen [19:37] Who started off with pointing out that conflict? [19:37] pitti and slangasek especially helped and guided me on that. stgraber also helped [19:37] I understood the issue from my background in testing and the community; going from LTS to LTS [19:38] the idea to make it a diversion over something like update-alternatives was guided by their advic [19:39] 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] Let me be clear as to why I'm asking this question. [19:40] 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] 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] 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] 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] 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] 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] rbasak, I think I've shown I seek consensus before uploading. I've actively tried to solve all of juju's issues [19:44] 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] 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] 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] balloons: Did you see my question? [19:47] 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] 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] rbasak, I want you to feel comfortable and understand. What further detail can I provide? [19:48] bdmurray, no I'm sorry. I did ask slangasek to comment, and I see pitti did add a comment [19:49] rbasak, are you concerned that giving rights to these packages means juju will revert to uploading things that shouldn't land? [19:50] balloons: correct. I don't think that's restricted to just you, either, to be clear. [19:51] Or even you at all. [19:51] 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] cjwatson: noted, thanks. [19:52] Does the inclusion of mwhudson and stokachu help alleviate those concerns? [19:53] 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] rbasak, ack [19:53] is this an easier consideration as a singular ppu? [19:54] and does anyone else have questions I might be able to answer? [19:54] That's effectively how I see the request already anyway. [19:55] Right, I think the discussion is about balloons having PPU upload rights for the identified juju packages. [19:55] Right - whether a packageset or not is just the mechanism. [19:55] We’re approaching 45 minutes on this subtopic…let’s get some final comments/questions, please. [19:56] Any thoughts on PPU with the caveat that PPU uploaders are to upload minor upstream updates and bugfixes only? [19:56] Or is that unhelpful? [19:56] 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] 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] 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] The problem is Juju is still in beta, so have him as a minor/bugfix only doesn't really help here [19:57] 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] 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] I’m ok with major updates in development releases, but major updates for SRU-exceptions seems a bit over-reaching. [19:58] That’s just me. [19:59] I’m also not familiar with juju’s development cycles and packaging. [19:59] So without that I don't feel that I@m ready to make up my mind either way. [19:59] That's all from me I think. [19:59] 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] balloons: But they granted that exception prior to your request for PPU, so we have to take that into account. [20:00] 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] BenC, absolutely. I want everyone to understand this isn't just an ordinary package [20:01] balloons: I think part of rbasak's concern is exactly because it isn't an ordinary package. [20:01] 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] 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] 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] I appreciate everyone's time and thoughts [20:03] rbasak: so can we count on you to help with the load of getting these packages uploaded? [20:03] 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] stokachu: really? [20:04] external dependencies> reminded of https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html [20:04] 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] bdmurray: we're stretched thin as it is [20:05] +1 to BenC's statement [20:05] 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] it's a reasonable request [20:05] And to be clear, balloons' request is entirely reasonable. [20:06] ok i just don't see any other solutions to help alleviate the bottleneck [20:06] 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] 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] bdmurray: im merely looking for alternate solutions [20:07] Maybe we should defer the vote for two weeks then? [20:07] That’s what I’m thinking as well. [20:07] 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] 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] balloons: Perhaps you could get some more endorsements in the mean time? [20:08] Would we like to discuss over mail? [20:08] I do appreciate the need here. I'd like to be able to give a path forward without undue delay. [20:08] CoC, etc. [20:08] I'm happy to enumerate, and I don't want anyone to feel rushed in this. [20:09] and BenC, absolutely. I think that's a good solution. It's hard to fill everyone in during a short IRC meeting [20:09] 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] balloons: do you understand exactly what that means? [20:10] I just want to make sure we aren't stalled on something where nobody knows what to do to make progress. [20:10] (I feel a bit like that right now) [20:10] For the record, I’m proposing deferring until next meeting for DMB, not to TB. [20:11] If we can’t decide at that meeting, we’ll either reject, or punt to TB. [20:11] rbasak, it sounds like people want some more details on the TB exception? [20:12] BenC: do you need anything else? [20:12] Nope [20:12] #accepted Defer vote on Nicholas Skaggs JuJu PPU until next meeting. [20:13] #action balloons Provide details on packaging issues and TB SRU exception for JuJu prior to next meeting. [20:13] ACTION: balloons Provide details on packaging issues and TB SRU exception for JuJu prior to next meeting. [20:13] #agreed Defer vote on Nicholas Skaggs JuJu PPU until next meeting. [20:13] * BenC kicks the bot [20:14] I don't think it replies to those. [20:14] The wiki is wrong, then. [20:14] #info Defer vote on Nicholas Skaggs JuJu PPU until next meeting. [20:14] I mean it notes those, but doesn't tell you it did. [20:14] Ah [20:15] balloons: Thanks for your time and patience. [20:15] #topic Review of previous action items === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Membershop Board Meeting | Current topic: Review of previous action items [20:16] #subtopic infinity to make permission changes for new PPU packages for GunnarHj (carried over) [20:16] Anyone know about that one? [20:16] still carried afaik [20:16] #subtopic infinity to add Otto PPU access to mariadb-10.0, mariadb-client-lgpl, and galera-3 [20:16] And this one? [20:16] hanging out with the other one [20:17] #subtopic bdmurray to find another TB member to grant Otto PPU access [20:17] bdmurray: This is your item to shine on :) [20:17] Uh oh, I didn't have any luck. [20:18] Carried on over… [20:18] The last three are marked done... [20:18] #topic Ubuntu Core Developer Applications === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Membershop Board Meeting | Current topic: Ubuntu Core Developer Applications [20:18] #subtopic Christian Ehrhardt [20:18] o/ [20:19] cpaelzer: Welcome, and thanks for wating through our previous discussion. [20:19] Care to kick off the conversation with a bit about your request for CoreDev? [20:19] sure [20:19] first of all hi [20:20] I work for in Server Team almost a year now [20:20] 49 weeks I think to be correct [20:21] 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] so I've had quite some time in bugfixes and merges over the last 12 months [20:21] just as background, I was before Mainframe Linux Performance and KVM specialist [20:22] so the main focus was dpdk (TL;DR I/O optimization via userspace based device drivers) [20:22] and recently qemu/libvirt which degraded a bit over the past [20:23] dpdk especially is a very ... [20:23] umm special package sometimes [20:23] I hate to say that having read the last 60 minutes with you :-) [20:23] but it isn't special in the same way at least [20:23] so a lot of work went into getting that mature [20:23] that means a lot of testing [20:24] Sorry, I’m a bit lazy at this point. Do you already have any upload privs? [20:24] a lot of packaging getting from basics to working runtime things aroudn it [20:24] sure feel free to stop after so much time already :-) [20:24] no I have no upload rights yet [20:24] In fact after doing all that a few months ago actually I decided I apply for a DPDK ppu only [20:24] No, I mean I don’t feel like digging myself, so asking you instead :) [20:25] but a few of my endorsers told me to strive for more given my work [20:25] 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] 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] which is your right anyway - no matter the histroy of my request [20:25] hehe [20:26] As I said I work on a lot of sevrer packages [20:26] for example plenty of ntp things recently [20:26] some clamav and others [20:26] a lot of merges [20:26] all these need more upload rights to get faster progress [20:26] Does your work usually have you floating to where the work is needed rather than taking ownership of a package or packages? [20:27] anything complex goes through team review anyway, but even there it would help to help others [20:27] well not totally floating [20:27] I'd say I have about 40% server Team packages in general [20:27] 30% dpdk [20:27] 30% whatever currently is the most important - but usually server Team package related [20:27] atm the last 30% are into qemu/libvirt for example [20:28] so floating in a sense that I usually care abotu many hings yes [20:28] but not in a sense that I don't know today what I'll do tomorrow [20:28] cpaelzer: Did you do any package work in Ubuntu before starting with the server team @ canonical? [20:28] 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] BenC: no there was no deb packaing before joining [20:29] bdmurray: yes the qemu/libvirt tasks just started a few weeks ago [20:29] bdmurray: it is in such a shabby state that I had to start writing tests at first [20:29] bdmurray: https://code.launchpad.net/~ubuntu-server/ubuntu/+source/qemu-migration-test/+git/qemu-migration-test [20:29] as plan to guide my coming uploads [20:29] and identify how much more issues we have [20:30] as I mentioned before my pre-Canonical time has quite a lot of KVM history [20:30] so qemu/libvirt isn't new to me [20:30] but you are right up until recently most sevrer Team work in that area has been taken care of by hallyn [20:30] (who left Canonical now) [20:31] 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] 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] 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] BenC: I would sign "Without a lot of knowledge, it can be easy to make packaging mistakes unintentionally" with blood [20:35] I happen to just ask when things are unclear which seems to be a forgotten feat these days [20:35] but surely [20:35] sometimes you just don't know you would have to ask before things happen [20:35] I'm well aware that I'm still on the rampup part of skill-rampup in regard to packaging [20:35] but to some extend I think one always is [20:36] I have seen even some of the overlords of our packaging sometimes wonder about some detail [20:36] it is just more details to me to still wonder about I guess [20:37] Knowledge is knowing you don’t know everything… [20:37] that is a nice summary to what I tried to say - yes [20:38] bdmurray, micahg: Any questions or comments? [20:39] 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] I am, however, inclined to say yes to PPU for server package set. [20:41] 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] 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] I have no questions. [20:43] Do any DMB members have concerns with me moving directly to a CFV on server-dev, preempting a core-dev vote? [20:43] Ok… [20:44] #vote Grant Christian Ehrhardt Server-Dev upload privs [20:44] Please vote on: Grant Christian Ehrhardt Server-Dev upload privs [20:44] 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] +1 [20:44] +1 received from BenC [20:44] +1 [20:44] +1 received from bdmurray [20:44] +1 [20:44] +1 received from micahg [20:45] +1 to make quorum, though I'd prefer to have self-recused as I'm a colleague [20:45] +1 to make quorum, though I'd prefer to have self-recused as I'm a colleague received from rbasak [20:45] #endvote [20:45] Voting ended on: Grant Christian Ehrhardt Server-Dev upload privs [20:45] Votes for:4 Votes against:0 Abstentions:0 [20:45] Motion carried [20:46] cpaelzer: Congrats on your new status! [20:46] cpaelzer: congratulations! [20:46] Thank you all [20:46] #topic Any Other Business === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology | Ubuntu Membershop Board Meeting | Current topic: Any Other Business [20:46] 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] 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] #action Christian Ehrhardt to announcements, add to ~ubuntu-server-dev and ~ubuntu-dev if required. [20:47] ACTION: Christian Ehrhardt to announcements, add to ~ubuntu-server-dev and ~ubuntu-dev if required. [20:47] AOB from anyone? [20:48] Who has that action? :) [20:48] rbasak: I assumed you were doing the honors? :) [20:48] OK :) [20:49] 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] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds: Please leave swords by the door | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendars | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [20:49] Meeting ended Mon Sep 12 20:49:30 2016 UTC. [20:49] Minutes: http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-09-12-19.08.moin.txt [20:49] I’ll update the agenda later this evening. Thanks everyone! [20:51] thanks everyone, I wouldn't have expected this to be so long and exhausting - I have to spend you a beer next time seeing any of you for doing all that for the community