15:01 <rbasak> #startmeeting Developer Membership Board 15:01 <meetingology> Meeting started Mon Nov 19 15:01:49 2018 UTC. The chair is rbasak. Information about MeetBot at http://wiki.ubuntu.com/meetingology. 15:01 <meetingology> 15:01 <meetingology> Available commands: action commands idea info link nick 15:01 <rbasak> #topic Review of previous action items 15:02 <rbasak> Adding Andreas to ~ubuntu-core-dev and sending announcements (done) 15:02 <rbasak> Looks like that can be cleared out. 15:02 <rbasak> No other previous action items. 15:02 <rbasak> #topic Ubuntu Core Developer Applications 15:02 <rbasak> I suggest starting with ddstreet as his application has been postponed multiple times from previous missed meetings. Any objections? 15:02 <sil2100> +1 on tha 15:02 <sil2100> *that 15:03 <cyphermox> yup, sounds good 15:03 <rbasak> #subtopic Dan Streetman 15:03 <rbasak> ddstreet: hello! Thank you for your patience with this. Could you introduce yourself please? 15:03 <ddstreet> hi i'm ddstreet, been using ubuntu since i started with canonical in 2015 15:03 <ddstreet> i'm part of the canonical sustaining engineering team, for reference re: canonical 15:04 <ddstreet> my application page is at https://wiki.ubuntu.com/ddstreet/coredeveloper 15:04 <ddstreet> for older history, been using linux since 1997 and unix since 1993 (solaris, college) 15:04 <rbasak> I have some questions, so shall I go first? 15:04 <ddstreet> mostly my work has been with the linux kernel, but more recently i've expanded/shifted into more userspace packages 15:05 <ddstreet> fine with me 15:05 <rbasak> We recently updated https://wiki.ubuntu.com/UbuntuDevelopment/DeveloperApplicationTemplate but I guess your application page predates that change. 15:05 <ddstreet> rbasak probably, i actually just copied over my sru-developer application and edited it 15:05 <rbasak> Please could you explain your goals in applying to be core dev? Is there anything in particular that you are blocked from doing now, where a successful application would unblock you? 15:06 <ddstreet> primarily 1) upload to devel release and 2) develop/maintain core tooling, e.g. ubuntu-dev-tools 15:07 <rbasak> OK. What sorts of uploads to the devel release are you expecting to make? 15:07 <ddstreet> bugfixes 15:07 <ddstreet> almost exclusively 15:07 <ddstreet> and then sru those fixes 15:07 <jbicha> ddstreet: I'm leaning towards voting no because it looks like your list of non-SRU uploads is pretty short & you already have upload rights to do SRUs 15:08 <rbasak> ddstreet: do you have specific examples of sponsored uploads of this nature done to the development release please? 15:08 <ddstreet> jbicha yep i've familiar with the 'no, moar' position from the dmb :) 15:08 <ddstreet> rbasak just whatever is listed in my upload history 15:08 <rbasak> It's hard to sift through those filtering for just the ones relevant to your "unblocking request", IYSWIM. 15:09 <rbasak> That's why we updated https://wiki.ubuntu.com/UbuntuDevelopment/DeveloperApplicationTemplate :) 15:09 <ddstreet> you mean, can i list specific uploads that i needed to have sponsored instead of being able to upload myself? 15:09 <rbasak> Right 15:09 <ddstreet> no i don't have that broken out 15:10 <rbasak> That's what I feel I ought to be assessing. 15:10 <ddstreet> i should also state, i plan to sponsor other's uploads to devel, as well, that wasn't clear from my initial statement 15:10 <jbicha> https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsoree=dan+streetman&sponsoree_search=name 15:10 <jbicha> I found that link on your application :) :) 15:10 <cyphermox> ddstreet: could you expand on the thought-process behind the fix for https://launchpad.net/ubuntu/+source/ebtables/2.0.10.4-3.5ubuntu4 ? seems like ignoring errors is generally worse than fixing whatever the underlying problem is, maybe there's some background I'm missing for ebtables 15:11 <ddstreet> cyphermox that was due to an issue with WSL; the package upgrade failed because the service stop failed, but that was because it never was able to start (or work) in the first place 15:12 <ddstreet> there is no reason to block package upgrade if the service stop fails, however 15:12 <ddstreet> for this particular pkg, at least 15:13 <cyphermox> I disagree; you generally do want to catch failures even if it's a stop -- if it doesn't stop and you try to start it after and it fails to start, you're not really in a better position 15:13 <rbasak> I see five bugfix uploads to the development release in the past 12 months I think. Are there any more? 15:13 <ddstreet> cyphermox for this particular service, nothing is running and there is no blockage to 'starting' it 15:14 <ddstreet> cyphermox there additionall was back-and-forth discussion for that bug and that approach was settled on, though i did suggest/discuss other approaches 15:14 <rbasak> And none of the sponsors from those five bugfix development uploads appear to have endorsed or commented on your application. Is there a reason for this? 15:15 <ddstreet> rbasak that's probbaly right i suppose 15:15 <ddstreet> i can't speak for sponsors, i have no idea why they ignored my request for endorsement/comment 15:17 <rbasak> What's your experience in getting uploads landed in the development release currently? 15:17 <rbasak> (ie. finding sponsorship) 15:17 <ddstreet> i can usually get slashd to upload to devel when he's around 15:17 <ddstreet> but i can't upload anyone else's devel fixes 15:17 <rbasak> OK, thanks. Does anyone have any further questions? 15:18 <ddstreet> and he's not always around or have time 15:19 <jbicha> no more questions from me 15:20 <tsimonq2> Hi, sorry I'm late. 15:21 <cpaelzer> sorry to interrupt, can I as a sponsor of ddstreet seeing the discussion going on ask a question as well? 15:21 <tsimonq2> cpaelzer: I don't see why not. 15:21 <tsimonq2> I'm personally ready to vote after talking with ddstreet the other day. 15:22 <rbasak> cpaelzer: absolutely 15:22 <cpaelzer> thanks, I mentioned that I can't speak for the usual complexities of a core-dev in my endorsement as I haven't touched those. I wonder if ddstreet would be able to identify a list of pacakages where getting PPU on these would solve 99% of his issue withut needing full core-dev 15:22 <cpaelzer> it seems there are a few common candidates that he is contributing to, and those might be a good first step to grow from there 15:22 <ddstreet> cpaelzer no, i think i do need core dev 15:22 <ddstreet> thanks for the suggestion though 15:23 <rbasak> OK. I think everyone is ready to vote then? 15:23 <ddstreet> i fully expect the dmb to vote me down with 'you need moar' though :) 15:23 <cpaelzer> could you outline why that is needed and a set of PPUs would not so that the group here can include that in the decision? 15:23 <ddstreet> cpaelzer i (and those i work with) fix a wide variety of packages 15:24 <ddstreet> and i need devel upload not just for myself but also to upload/sponsor others 15:24 <tsimonq2> Are they the same packages (but a lot of them)? 15:24 <ddstreet> additionally, much of what i want to do as core dev is fix the lack of tooling to make it easier for others to prepare their uploads for sponsors 15:24 <ddstreet> and, allow sponsors to much more easily check off the long list of upload items without manually looking to make sure uploads meet each item 15:25 <ddstreet> tsimonq2 all pkgs in main plus quite a lot in universe, if that's what you are asking 15:25 <tsimonq2> That would be a good idea ddstreet have you proposed your ideas? :) 15:26 <tsimonq2> s/ /, / 15:26 <tsimonq2> ddstreet: I see. 15:26 <ddstreet> tsimonq2 i have a long history of rewriting ubuntu-dev-tools pull-* tooling 15:26 <ddstreet> that i'm waiting to get coredev before i push to ubuntu-dev-tools git 15:26 <ddstreet> as well there needs to be tooling to check debdiffs instead of having to check them manually 15:27 <cyphermox> ddstreet: I don't understand that comment? tooling to avoid manually looking over uploads? 15:27 <tsimonq2> ddstreet: And I have a long history of nagging mapreri to merge your changes already :P 15:27 <tsimonq2> (He's a sponsor of mine.) 15:27 <ddstreet> cyphermox yep; check version number, changelog formatting; LP: # tag, run autopkgtests, build, etc. 15:27 <rbasak> I've discussed ddstreet's proposals in the past. I have no objection to them, but I've been focused on the same problems but using git instead, and I prefer to focus my time there. 15:27 <cyphermox> mmkay 15:27 <ddstreet> tsimonq2 mapreri already discussed and agreed that i would push my changes, not him 15:27 <rbasak> ("git ubuntu lint" etc) 15:28 <ddstreet> as my changes will be ongoing, and waiting another year+ for 'review' and upload of my chagnes isn't sustainable 15:28 <cyphermox> yeah. it's not bad, just won't ever be a replacement for eyes 15:28 <ddstreet> rbasak git ubuntu doesn't cover all pkgs in ubuntu 15:28 <rbasak> Unfortunately the nature of the changes means that it's a big review. 15:28 <rbasak> ddstreet: the plan is that it will :) 15:28 <ddstreet> IMHO much of git ubuntu backend functionality should go into a lib 15:28 <rbasak> For now we accept individual additions to the whitelist 15:29 <rbasak> git ubuntu backend functionality _is_ a lib :) 15:29 <ddstreet> right but you restrict that functionality to only the git ubuntu tool 15:29 <jbicha> I understand the desire to avoid sponsoring, but your application here would be stronger if you had a longer list of things that have been sponsored or at least in the sponsor queue 15:29 <rbasak> Admittedly it's not split out 15:29 <tsimonq2> +1 jbicha 15:29 <ddstreet> rbasak well, if it's not split out, that's not really a usable public lib then :) but i get your point 15:29 <rbasak> Much functionality depends on being able to read what's there, and that's made much easier by relying on a single format (git and the nature of the git-ubuntu trees) in order to make that work. 15:29 <ddstreet> jbicha yeah i know, 'moar' 15:29 <ddstreet> :) 15:30 <cyphermox> rbasak: otoh, linting is not git-specific 15:30 <rbasak> So I think there's probably not much benefit in exporting API to share code in this case. 15:30 <rbasak> cyphermox: it absolutely is! 15:30 <tsimonq2> Anyway, are we ready to formally vote? 15:30 <ddstreet> rbasak we can certainly discuss git ubuntu later if you want :) 15:30 <cyphermox> rbasak: not checking that a package is sane :) 15:30 <cyphermox> yeah, I think we're ready to vote 15:30 <rbasak> cyphermox: linting needs to look at what's there already, how the archive looks, etc. In git-ubuntu we do it by examining the repo. There are other ways, but no reason for git-ubuntu lint to not use what's there. 15:30 <rbasak> But then there's less commonality with a non-git approach. 15:30 <rbasak> Anyway 15:31 <rbasak> Let's move on to vote then. 15:31 <cyphermox> rbasak: that's not what he was talking about -- it was mostly just looking at the control and stuff 15:31 <rbasak> #vote Approve ddstreet's core dev application 15:31 <meetingology> Please vote on: Approve ddstreet's core dev application 15:31 <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname) 15:31 <rbasak> -1 detailed reasons to follow 15:31 <meetingology> -1 detailed reasons to follow received from rbasak 15:31 <tsimonq2> -1 I'd like to see more devel work. 15:31 <meetingology> -1 I'd like to see more devel work. received from tsimonq2 15:32 <sil2100> +0 (I know Dan's SRU work and I know his capable, but I would need to see a bit more devel work and demonstration of devel knowledge (aka. moar)) 15:32 <meetingology> +0 (I know Dan's SRU work and I know his capable, but I would need to see a bit more devel work and demonstration of devel knowledge (aka. moar)) received from sil2100 15:32 <sil2100> s/his/he's/ 15:32 <ddstreet> ah, moar, what a surprise ;-) 15:32 <cyphermox> -1 ; as for the others; would like to see more non-SRU, devel work -- merges, more -proposed, etc. 15:32 <meetingology> -1 ; as for the others; would like to see more non-SRU, devel work -- merges, more -proposed, etc. received from cyphermox 15:33 <jbicha> -1 insufficient non-SRU uploads (or evidence of other core-dev work). Sorry 15:33 <meetingology> -1 insufficient non-SRU uploads (or evidence of other core-dev work). Sorry received from jbicha 15:33 <rbasak> Is that everyone? 15:33 <rbasak> #endvote 15:33 <meetingology> Voting ended on: Approve ddstreet's core dev application 15:33 <meetingology> Votes for:0 Votes against:4 Abstentions:1 15:33 <meetingology> Motion denied 15:33 <rbasak> My detailed reasons: 15:33 <rbasak> I'm OK in principle with granting core dev for the purposes of landing bugfixes in packages in main in the development release, without having wider experience that I'd normally expect from a core dev applicant, if that is going to unblock progress. However, in that case, I'd expect a strong application. In this case, you have only five sponsored uploads in the past twelve months, which perhaps is 15:34 <rbasak> only just on the line of demonstrating need, and no endorsements from any of your recent sponsors for this class of uploads. For this reason, I'm afraid I'm -1 for now. I welcome a reapplication once you have some of: a higher rate of sponsored uploads to the development release; strong endorsements from your sponsors for this type of upload. 15:34 <rbasak> I wrote up some general personal opinions on what I look for in a core dev application here, which I hope will also help: https://wiki.ubuntu.com/RobieBasak/DMB/CoreDev 15:34 <rbasak> FWIW, no endorsements from sponsors for uploads directly related to the application means an automatic -1 from me, without an exceptional reason. 15:34 <rbasak> Nothing to do with "moar". 15:36 <rbasak> ddstreet: sorry we couldn't approve your application on this occasion. But we do appreciate your work, and hope you will continue with sponsorship for the time being. We welcome you to apply again once the concerns raised here have been addressed. 15:36 <ddstreet> yep, already rescheduled myself for 2 wks from now :) 15:36 <jbicha> I know it's pretty discouraging to be told "no" here, but please do work on strengthening your application & apply again in a few months 15:36 <jbicha> lol 15:36 <ddstreet> jbicha it's really no surprise at all - been thru this already with sru-devel application 15:37 <rbasak> Could a DMB member volunteer to follow https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_an_unsuccessful_application please? 15:37 <rbasak> I guess I'll do it 15:37 <rbasak> #action rbasak to close ddstreet's application 15:37 * meetingology rbasak to close ddstreet's application 15:38 <rbasak> #subtopic Tiago Daitx 15:38 <jbicha> thanks, I was too slow 15:38 <rbasak> tdaitx: hello! Thank you for your patience. 15:38 <rbasak> Please could you introduce yourself? 15:38 <tdaitx> hi! I'm Tiago Daitx. My core dev application is available at https://wiki.ubuntu.com/TiagoDaitx/CoreDeveloperApplication 15:38 <tdaitx> I have been on the Ubuntu Foundations team for a bit over 3 years now 15:38 <tdaitx> when I joined I barely had any experience with packaging - which is pretty unusual for foundations 15:39 <tdaitx> what I had was experience with openjdk and thus my main focus was on openjdk maintenance and security updates 15:39 <tdaitx> that includes backporting security patches from newer openjdk versions 15:39 <tdaitx> and of course packaging 15:39 <tdaitx> on that side I have worked on openjdk-6, 7, 8, 9, 10, and now 11, from precise to disco, including the openjdk migration from 8 to 9/10/11 15:40 <tdaitx> in addition to that I have helped on merges, FTBFS and autopkgtest fixes, srus, and a few migrations 15:40 <tdaitx> that said I don't recall ever dealing with a NBS 15:40 <cyphermox> it's not as much an issue with things being in proposed. 15:40 <cyphermox> (in a way, it is, but not quite as when the docs were written) 15:41 <tdaitx> so my sponsors have requested me to go and ask for coredev 15:41 <jbicha> I'm curious about the status of the openjdk-11 transition for bionic 15:41 <tdaitx> jbicha: I have a list of packages that need to be sru before openjdk-11 15:42 <jbicha> do you have a tracker bug for it? 15:42 <tdaitx> after bootstraping those I can move to openjdk-11 itself 15:42 <tdaitx> and the other packages 15:42 <tdaitx> currently it is being tracked in a trello card 15:43 <tdaitx> I was working on the openjdk-8 and openjdk-10 fixes after a regression from the last security update 15:43 <jbicha> is that a public card? do you have a link? (sorry for perhaps going a bit off-topic here) 15:43 <tdaitx> and also the openjdk-7 security update 15:43 <tdaitx> I don't think it is public, it is under the foundations team board 15:43 <tdaitx> let me check 15:44 <jbicha> ok, no problem today if it's not public 15:44 <tdaitx> yeah, it is not 15:44 <jbicha> I guess my context was user complaints in bug 1796027 15:44 <tdaitx> with the security updates out of the way I will start now moving into the migration 15:44 <ubottu> bug 1796027 in openjdk-lts (Ubuntu) "Update openjdk-11 to 11.0.1 -> Backport it from Ubuntu 18.10" [Undecided,Confirmed] https://launchpad.net/bugs/1796027 15:46 <tdaitx> jbicha: yeah, I am aware of that, but first we had to deal with getting openjdk-11 in cosmic 15:46 <tdaitx> and all the security updates out 15:46 <tdaitx> for now I have updated openjdk-lts (openjdk-10) in bionic with the security patches from 11.0.1 15:46 <rbasak> Am I right in thinking this is an application to go direct to core dev - you can't currently upload anything directly? 15:46 <tdaitx> so security wise openjdk-lts in cosmic is good 15:47 <tdaitx> rbasak: you are correct 15:47 <tdaitx> I never applied for openjdk upload rights because all uploads go through the security team anyway 15:48 <tdaitx> and apart from it there is no particular package that I work on, I just look at whats broken and where people need some help 15:49 <tdaitx> I considered motu, but I was told by sponsors/people on my team to go directly to coredev, which is understandable as it covers various packages we work on 15:49 <rbasak> Have you ever handled a transition? 15:50 <jbicha> no more questions from me 15:50 <tdaitx> yes, altought it it has been some time 15:50 <tdaitx> I helped on the gcc5 transition 15:51 <rbasak> Can you tell me how you might detect if an upload might trigger a transition, and what you'd do if you find that to be the case? 15:52 <tdaitx> what I recall is that abi/api changes which require a new lib version which will end up causing a transition 15:53 <tdaitx> so every package that (build-)deps on it will need to be rebuild 15:53 <tdaitx> and possibility fixed if there are incompatibilities 15:54 <rbasak> OK. Good answer from the technical side. But what about the coordination side? What would you do to coordinate it? 15:55 <tdaitx> well, first making sure the teams that have packages which would need to go through the transition know about it 15:55 <tdaitx> then discuss it and make sure there is consensus on how to approach it 15:55 <rbasak> OK thanks 15:55 <rbasak> I have one final question. 15:56 <rbasak> For a jump-straight-to-core-dev application, it seems to me that you have very few endorsements, given that you have a wide range of core dev sponsors many of whom are on your team at Canonical. 15:56 <rbasak> Is there a reason for this? Have you asked for more endorsements? 15:56 <rbasak> Or is there some expectation that more endorsements weren't necessary? 15:57 <tdaitx> I did ask for the endorsements on my team's channel and also for a few other people I worked with 15:57 <tdaitx> I didn't really go around pushing people for it, I assumed 3 would be good enough 15:57 <tdaitx> for which 2 are from my team 15:58 <rbasak> OK, thanks. 15:58 <rbasak> Everyone ready to vote? 15:58 <slashd> o/ 15:58 <slashd> rbasak, yes I'm here 15:58 <sil2100> I have one last question 15:58 <rbasak> Sure 15:59 <sil2100> tdaitx: did you have any experience in parsing update_output? 15:59 <slashd> sorry need to change my calendar since I have move the time in Canada 15:59 <tdaitx> no experience in actually parsing it, i have looked at it 16:00 <sil2100> tdaitx: when would you consult update_output usually? Do you know any use-case of it? 16:02 <tdaitx> so I usually go for update_excuses, I remember using update_output very fews times, but that was about 2 years back 16:04 <tdaitx> I think it was about the gcc5 transition 16:04 <tdaitx> sil2100: can't really remember why I needed it though, sorry 16:04 <tdaitx> I had steve helping me back then 16:05 <sil2100> tdaitx: yeah, during those it might also be useful - usually when a package is marked as 'valid candidate' but doesn't want to migrate due to some strange uninstallability issue 16:05 <cyphermox> ready to vote? 16:05 <sil2100> Yep, ready 16:06 <rbasak> #vote approve tdaitx's core dev application 16:06 <meetingology> Please vote on: approve tdaitx's core dev application 16:06 <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) 16:06 <rbasak> -1 I'm generally satisfied with everything I've seen, but I'm concerned about the lack of endorsements from the majority of your recent sponsors, especially for a jump straight to core dev which makes sense in your case but I think still requires a stronger-than-normal application. Get positive endorsements from your recent sponsors please; if they are in support of your application this shouldn't 16:06 <meetingology> -1 I'm generally satisfied with everything I've seen, but I'm concerned about the lack of endorsements from the majority of your recent sponsors, especially for a jump straight to core dev which makes sense in your case but I think still requires a stronger-than-normal application. Get positive endorsements from your recent sponsors please; if they are in support of your application this shouldn't received from rbasak 16:06 <rbasak> be difficult. If they aren't in support of your application, then that is cause for concern. 16:06 <cyphermox> +1 16:06 <meetingology> +1 received from cyphermox 16:06 <tsimonq2> +1 16:06 <meetingology> +1 received from tsimonq2 16:06 <jbicha> +1 thanks for your Java work 16:06 <meetingology> +1 thanks for your Java work received from jbicha 16:07 <tdaitx> jbicha: thanks =) 16:07 <tsimonq2> slashd? 16:07 <tdaitx> rbasak: ack, I will look into that 16:07 <rbasak> FWIW, with endorsements from others in your team I'll be an automatic +1 16:08 <rbasak> It's down to slashd I think as to whether you'll need to do that. 16:09 <slashd> give me 1 minute to read down, sorry I'm late with due to the time change 16:09 <rbasak> np 16:12 <slashd> +1 based on what I read above, I don't want to take much time, as I'm the one being late to the party 16:12 <meetingology> +1 based on what I read above, I don't want to take much time, as I'm the one being late to the party received from slashd 16:12 <rbasak> I think that's everyone here. 16:12 <sil2100> +1 16:12 <meetingology> +1 received from sil2100 16:12 <rbasak> Or not 16:12 <sil2100> (otherwise we'd have to wait for those that are absent) 16:13 <rbalint> rbasak, i have not sponsored uploads from tdaitx but from following his work and interactions on irc and email i'd give a +1 16:13 <rbasak> Now it is with only one absent team member I think? 16:13 <rbasak> rbalint: thanks! I think maybe it doesn't matter now? 16:13 <rbasak> #endvote 16:13 <meetingology> Voting ended on: approve tdaitx's core dev application 16:13 <meetingology> Votes for:5 Votes against:1 Abstentions:0 16:13 <meetingology> Motion carried 16:13 <tsimonq2> Congrats. :) 16:13 <rbasak> Yes it can't be overturned by -1 from absent members. 16:13 <tdaitx> \o/ 16:13 <rbasak> Congrats tdaitx! Thank you for your work! 16:13 <rbalint> tdaitx, \o/ :-) 16:13 <tdaitx> omg thanks folks! 16:14 <rbasak> Can a DMB member volunteer for https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_a_successful_application please? 16:14 * tsimonq2 raises hand 16:14 <rbasak> Thanks! 16:14 <rbasak> #action tsimonq2 to make ACL changes for tdaitx's successful application 16:14 * meetingology tsimonq2 to make ACL changes for tdaitx's successful application 16:14 <rbasak> #action tsimonq2 to announce tdaitx's successful application 16:14 * meetingology tsimonq2 to announce tdaitx's successful application 16:15 <tsimonq2> AOB now? :) 16:15 <tsimonq2> (I have an item.) 16:15 <rbasak> Nearly 16:15 <rbasak> #topic Outstanding mailing list requests to assign 16:15 <rbasak> Anything there? 16:15 <tsimonq2> Ahh. 16:16 <rbasak> There's Aron's packageset request 16:16 <rbasak> And vala-panel from Martin 16:17 <rbasak> And general packageset update requests, eg. Rik. 16:17 <rbasak> Any volunteers? 16:17 <cyphermox> volunteers to respond? 16:17 <rbasak> To handle those requests, yes 16:19 <cyphermox> yup, sure 16:19 <rbasak> Thanks! 16:19 <rbasak> #action cyphermox to handle the recent three packageset requests 16:19 * meetingology cyphermox to handle the recent three packageset requests 16:19 <rbasak> #topic AOB 16:19 <rbasak> tsimonq2: over to you. 16:19 <tsimonq2> Quick (slightly offtopic) question that someone here might know the answer to. 16:19 <tsimonq2> Where does the udevbot code live? cyphermox proposed on ubuntu-devel a month or two back that +1 maintenance could be done in the patch pilot style as well (plus sponsoring, FTBFS, etc.) so it'd be good to have a key for it. 16:19 <tsimonq2> It's DMBish in nature. 16:20 <cyphermox> tsimonq2: not really 16:20 <cyphermox> it's not owned by the DMB anyway 16:20 <rbasak> I'm not sure the current DMB people will know :-/ 16:20 <cyphermox> that's up to the IRC team really. 16:20 <rbasak> I guess out of scope for this meeting then. 16:20 <tsimonq2> Got it. I'll continue asking around then, I think... 16:20 <rbasak> Try #ubuntu-devel more generally maybe? 16:20 <rbasak> Any other AOB? 16:21 <tsimonq2> rbasak: I did a few days ago. 16:21 <rbasak> Keep trying :) 16:21 <tsimonq2> OK :) 16:21 <rbasak> Or email ubuntu-devel@ maybe? 16:21 <tsimonq2> Good ideam 16:21 <tsimonq2> s/m/./ 16:21 <rbasak> OK, thanks all! The next meeting will be in two weeks at 1900 UTC. 16:21 <rbasak> #endmeeting