[14:06] rbasak: wasn't a DMB board supposed to happen right now? [14:12] mapreri: it's at 1600 *UTC* [14:13] oh, why did I think 16 CEST [14:13] I did email you about that, but IIRC it bounced because your email provider refused it. [14:13] did you use @ubuntu.com ? [14:13] mapreri: https://lists.ubuntu.com/archives/devel-permissions/2022-July/001998.html [14:13] Probably [14:13] ohh [14:14] that table is quite clear it's 16 UTC, wth was I thinking [14:14] sorry [14:14] guess I'll come back in 1h45m then… [14:15] Good thing the error was this way round :) [16:00] o/ [16:00] Who is here? [16:00] And who is available to chair please? [16:02] Hello - I'm here ... [16:02] I'm here but i need to leave in half an hour [16:03] I'm here but cannot chair. [16:03] sil_2100 is out AIUI [16:04] fheimes: did you announce your application on the devel-permissions@ ML? [16:04] I don't see anything recent there from you [16:04] mapreri: are you here? [16:04] * mapreri is back [16:05] oh -dear - no, just on the agenda (my previous ann. is to far away) [16:05] so guess I'd better use another DMB meeting then (sending again an a.. out to the ML) ? [16:05] I don't think it's necessary for you to postpone unless others object. [16:05] But please could you send an announcement to devel-permissions@ now anyway? That sets up the thread which ends up being a record in the archive, etc. [16:06] I guess I'll chair then. [16:06] ok, do it right now [16:06] Utkarsh and Lucas have already voted on mapreri's application, so we're quorate for that. [16:06] rbasak: no meetinglogy? [16:06] I suggest we also proceed with fheimes (assuming we have time), and we might find ourselves needing a fourth vote. [16:06] #startmeeting Developer Membership Board [16:06] Meeting started at 16:06:53 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology [16:06] Available commands: action, commands, idea, info, link, nick [16:07] Let's just dive straight in to the applications as we'll be pushing for time anyway. [16:07] #topic Ubuntu Core Developer Applications [16:07] #subtopic Mattia Rizzolo [16:07] mapreri: o/ could you introduce your application please? [16:07] #link https://wiki.ubuntu.com/MattiaRizzolo/CoreDevApplication [16:08] Hello everybody. I believe my application page says it all, but for a very short introduction: I've been around Ubuntu for more than a decade now, and doing random dev stuff since 9 years (2013 was when I started messing with packages). Although I kind of artificially postponed my MOTU until 2016... [16:09] Your sponsorship miner suggests that in the past two years you've only made two uploads into Ubuntu. Is this accurate? [16:09] over time I found myeslf touching packages in main every so often, even if not exactly "all the day", and with the experience I have as a Debian Developer I figured it wouldn't be too much of a bad fit to get this extra hat and makes several people life easier [16:10] that… inaccurate I believe [16:10] let me check [16:10] or well, who knows [16:10] I don't honestly keep track [16:10] *appears* [16:10] (sorry i was on a walk) [16:11] fwiw, I also reckon I asked people around to click the autopkgtest retry button every so often as I didn't seem to have enough permissions [16:13] So basically your entire set of sponsors through 2021 and 2022 are ginggs, for those two. AFAICT. And he hasn't endorsed your application. Utkarsh also mentioned this, and asked for a reason. Could you answer that same question here please? [16:14] answer is that he kept saying he would have done it "in time for the meeting" but then never did :3 [16:14] btw [16:14] "only made two uploads into Ubuntu" - those are the sponsored ones [16:14] so I suspect only 2 in main, however including universe I count 66 uploads [16:14] and main for which I have PPU (say, devscripts) [16:14] MOre are listed here, but it folds entries for the same package/series IIRC: https://launchpad.net/~mapreri/+uploaded-packages [16:15] udd=> select source, version, date from ubuntu_upload_history where changed_by_name = 'Mattia Rizzolo' and date >= '2021-01-01'; [16:18] I have some further questions, but before I continue, does anyone else have questions for mapreri? [16:18] mapreri: Could you remind up what packages you have PPU for? [16:18] s/up/us/ [16:20] (I don't) [16:20] bdmurray: afaik devscripts, strip-nondetermism, inkscape, pbuilder, libroffice-dictionaries [16:20] not sure if I have more tbh, but I'm pretty sure I've got those [16:21] mapreri: when's feature freeze for Kinetic, please, and after feature freeze, how do you determine if an upload would be acceptable or not? [16:24] rbasak: https://wiki.ubuntu.com/KineticKudu/ReleaseSchedule → August 25th. not acceptables includes new packages, new API, and well… new features. normally I'd seek exceptions for, say, new upstream releases that are mostly bugfixes but with tiny new features, or perhaps very leaf packages that have difficulty regressing the whole system. [16:25] mapreri: OK, thanks. Next question: how would you get a quick idea of whether a package upload might trigger a transition or not? [16:25] (the latter of which pretty much never applies for main packages, fwiw…) [16:27] rbasak: well… a new soname? or moving provides around? or switching some kind defaults (like mpi-defaults)? and if any of the previous matching, verifying whether there are any rdep. [16:27] unless you are one of those that think that python packages changing API severely should also be handled as a transitions, but strictly speaking for me it's not [16:28] (though it of course wouldn't be bad to stage those things properly too, sure) [16:28] OK, thanks. Next question: what's your opinion on peer review? You say "I feel I'm competent enough to not need somebody to review my work most of the time". Does that mean you don't intend to get peer review ever again when you are a core dev? [16:29] hardly. I regularly seek opinions of other whenever I find myself implementing something that can cause widespread changes (like i do during my devscripts maintenance work). [16:30] from my POV, the FFe process is also a kind of peer review [16:30] OK, thanks. I think I'm done with my questions. [16:30] Does anyone else have anything else they'd like to raise? [16:31] I know that there are plenty of auto-approvals in place (also during final freeze), but I know better than to go around its back, and instead open an FFe [16:31] (as an example) [16:31] or, also now I uploaded debhelper to focal-bpo, but I'm leaving it to others to review, even if I'm confident it's fine [16:33] #vote Grant mapreri core dev [16:33] Please vote on: Grant mapreri core dev [16:33] Public votes can be registered by saying +1, -1 or +0 in channel (for private voting, private message me with 'vote +1|-1|+0 #channelname') [16:34] +1 [16:34] +1 received from seb128 [16:35] +1 [16:35] +1 received from bdmurray [16:36] My vote/reasoning is a bit long... [16:38] mapreri has barely had anything requiring sponsorship in the last couple of years, and his sponsor has not provided an endorsement. Normally, in the absence of some other need, I don't think a "pre-emptive" application like this would be acceptable. I'd expect to see activity in the area requested and recent sponsors endorsing the applicant. The need to be able to retry autopkgtests is valid, but [16:38] seems weak given the rest of this application. [16:38] This makes the statements "I'd like to eliminate delays in getting my work sponsored" and "I'd like to reduce the burden on my sponsors" in this application moot, IMHO. [16:38] However, I think mapreri is a special case. This application has many strong endorsements. But additionally, I'm personally aware of their high degree of competency for many years. I'm certainly very happy with the answers to my technical/social questions. So I'm making an exception here and giving my +1 even though this application falls short of my normal criteria, on the basis of "well, [16:38] obviously this person will be valuable to Ubuntu as a core dev" and because, based on my personal experience, I have no doubts whatsoever that mapreri has the right combination of technical competency, diligence and collaborative ability. [16:38] +1 [16:38] +1 received from rbasak [16:38] +1 [16:38] +1 received from teward [16:39] You also have proxy +2 from Lucas and Utkarsh [16:39] #endvote [16:39] Voting ended on: Grant mapreri core dev [16:39] Votes for: 4, Votes against: 0, Abstentions: 0 [16:39] Motion carried [16:39] I'm actually very happy to read those words from you, rbasak ! [16:39] Congrats! [16:39] congrats! [16:39] and sorry I need to drop now [16:39] Thank you, everybody! [16:40] Could somebody volunteer for https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_a_successful_application please? [16:40] mapreri Congrats! [16:40] rbasak: depends, can i get a coffee first? :P [16:41] Sure, thanks :) [16:41] #action teward to announce mapreri's successful application [16:41] ACTION: teward to announce mapreri's successful application [16:41] rbasak, thanks for the exception [16:41] #action teward to make ACL changes for mapreri's core dev status [16:41] ACTION: teward to make ACL changes for mapreri's core dev status [16:41] ... after coffee run :P [16:41] I'm pretty sure ginggs was just overbusy, I remember he was going to advocate him too, but ELIFE happened :) [16:42] * genii twitches [16:42] #subtopic Frank Heimes [16:42] I'm pretty sure he was upset I picked this date as we were at debconf and today is a travel day [16:42] also me I'm going afk now and fall asleep! [16:42] fheimes: hello! [16:42] thank you again, and o/ [16:42] Hello ! [16:42] #link https://wiki.ubuntu.com/FrankHeimes/MOTU [16:42] (good luck fheimes !) [16:42] thx [16:43] i think i've poked some of your packages before... not sure, I always forget which stuff lands on my desk when im' in a sponsoring mood xD [16:43] I've updated the wiki page a bit [16:43] please also look for the section: "Updates since ..." [16:43] or at the very least i've reviewed / opinioned on your stuff [16:43] yes, that could well be ... [16:44] * fheimes is often working on more "alien" architectures ... [16:45] well i'mma steal your brain after the meeting then, your alien arch experience might be helpful in a few things i'm poking. but anyways, back to the meeting. *reviews the application* [16:45] sure (any time) [16:46] fheimes: feel free to introduce your application. [16:46] Does anyone have questions for fheimes please? [16:46] We don't have very long :-/ [16:46] Sure - First of all I apologize to not having sent out the ann. of the appl. earlier - but it's out now. [16:46] I'm Frank (Heimes), living in Germany, joined Canonical in '16 and I'm working Partner Engineering' (former 'hardware enablement' (former 'hyperscale')) team. [16:46] So I'm working with partners, especially with a specific one. [16:47] The areas and topics I'm working on are mainly the s390x and ppc64el projects, but not limited to these. [16:47] I think looking at universe packages is a good start and I worked on several universe packages (but also on some from main - see MOTU-appl. wiki page) - I guess more than half of them are s309x specific. [16:48] That's the reason I'm applying for the MOTU mebership (contributing developer) application - to be able to do more on the universe ones, w/o having to annoy others (sponsors) too much. [16:48] Do you have PPU for anything at the moment? [16:48] Since Jan I spent some more focus on merge and syncs (like you can see on the MOTU wiki page). [16:49] No I do not have PPU rights (but thought about them) [16:49] fheimes: Do you have a rough estimate of the ratio of main to universe packages you work on for a specific partner? [16:50] well - 20- to 25% main, the rest universe ?!   (not talking about kernel) [16:50] Let's say that package foo is on version 1.3.15, and you are considering uploading 1.3.16 but feature freeze is already passed. What do you need to consider to determine if this would be acceptable? [16:50] but a really rough est. ... [16:52] so after feature freeze / debian import freeze,  this would be a FFe (feature freeze exception) - I worked on some [16:52] I would go to the wiki and (re-)read about the possible exceptions [16:52] a new package would be acceptable in this case if it is for example a "bug fix only" release [16:52] How would you determine if it's a "bug fix only" release or not? [16:53] I would have a look at the delta between the two version (for example on the upstream git repo) and have a look at the commits that make up the delta [16:53] if these all all fixes, then I would consider this as bug fix only release [16:54] I have btw. worked on such a case in prep for 22.04 -  it was openssh-ibmca [16:54] OK, thanks [16:55] Do you understand your endorsement feedback about pcre2? [16:55] other "exceptions" are for example  high-priority cases [16:55] For example, in that case, with the benefit of hindsight, what specifically would have alerted you to the issue before upload? [16:55] about the transition? yes I think so [16:56] it is important to know what is all triggered by an upload (especially a library upload) [16:56] therefor I was keen on working on the libica3 to 4 migration (again in prep for 22.04) [16:56] since this triggered a transition ... [16:57] If build dependencies change significantly or are updated with a new version that comes with API/ABI changes, a rebuild of all packages that need that build dependency is needed (and a retest is also needed). [16:57] What would you look at in a local test build of your proposed upload in order to determine if a transition would be triggered? [16:58] (but let me double-check the endorsement again, so that I didn't missed anything ...) [16:58] To be clear, your answer is correct; I'm just trying to determine if you know what to look for specifically, as opposed to a general understand of the issue. [16:58] I would look at the reverse dependencies (of the source package), like: [16:58] reverse-depends -a source src:libica [16:58] (I see) [16:59] but there are more ways to figure out reverse depndencies - but I think this is a good way ... [16:59] OK. Next question: if a partner asks you to add a patch to a package that's in universe (since you're applying for MOTU), how would you determine if that change is acceptable for Ubuntu? [17:00] if I get some rev. deps listed [17:00] I re-build these based on the package that is in discussion [17:01] well, there are several things: [17:01] first I always look for and ask is this is upstream [17:01] because we don't want to carry oot patches (as usual there are some exception to this rules ... in case of potential data loss etc) [17:02] then I look at the patch itself, how it's licensed, does it harm the code, is it of real value for an SRU [17:03] What about ongoing maintenance? Are you prepared to maintain a patch in universe indefinitely if you upload or sponsor it? [17:03] esp. in case of an SRU, rules are a bit more strict [17:03] hence one also needs oto fill out the  SRU template and create a justification [17:05] well, in case of my particular partner there is an agreement in place that it will be maintained [17:05] but of course nobody wants to maintain it (oot) for ever [17:05] hence a strong focus is on getting it upstream accepted, so that this particular patch is at least no longer needed once the package gets version bumped [17:05] that is btw. what I did with tigervnc [17:05] OK, thanks. Next question: if a package you uploaded is "stuck in proposed", what do you need to do next? [17:07] first of all I try to identify reasons why this is the case [17:07] (could be outstanding verifications) [17:07] where I may work on myself, or with the partner (in case of special hw needs) [17:07] if I don't see and find a reason I would probably ask - one from SRU team [17:07] What if a package was stuck in -proposed for the development release? [17:09] well, after beta and rc things become more restrictive, even for a development release and I may turn it into a FFe [17:09] but if a package is in -proposed - even prior to the FF it should still be eligible for an update [17:10] and for the development release, the SRU team is no longer responsible [17:11] (in this case I would probably ask on the archive admins) [17:12] I'm having some doubts in your understanding of some of the details here. Both in proposed migration, and in identifying transitions. [17:12] well, if this is not what you wanted to hear, can you please be a bit more specific? [17:13] I'm not sure how the others feel, but this gives me some hesitation in voting for MOTU, but I think PPU may be more appropriate to give you an immediate path forward. [17:13] Yes of course I will go into details. [17:13] Have you done any +1 maintenance? [17:14] I mean if at some point in time the development is over the the new version got released, then the only way to get "meaningful" updates in the is SRU process [17:14] If not I think a couple of shifts would provide valuable experience in this area. [17:14] Would PPU for some specific packages be useful to you if your MOTU application is not successful today? [17:14] no, I (actually our team) doesn't do +1 maintenance [17:14] Specifically, for transitions I was expecting you to be able to identify a change in the binary package names output from your proposed upload as a suitable flag to identify most transitions. However I've not checked if that case applied to that example. [17:15] I think so - but this would of course limit me to these ... [17:15] For proposed migration in the development release, there's the excuses page, and a bunch of documentation for that: https://wiki.ubuntu.com/ProposedMigration. For a MOTU application I expect an applicant to be familiar with this process. [17:16] well, one example of such a change would be in case of a library - when it goes from let's sa libica3 to libica4 [17:16] yes, I know that page [17:17] and also know update excuses [17:17] e.g. blockers, failed tests failed dependencies [17:17] I'm sorry that I'm running out of time today. If you think that you meet my expectations in your understanding, then I'm happy to continue asking questions to help give me confidence about that, but I am running out of time to do that today. [17:18] i have a hard stop right now (FT job is needing my attention in a critical emergency infra meeting) so I don't have the time to ask any questions beyond what has already been asked, and i think we're all running out of time today anyways. do we want to postpone this until a later date for us to review/question, or do we want to vote based on what we've witnessed today? (I'm not against postponing things) [17:19] (unrelated: redis-server defaults are evil) [17:19] Seb had to leave and I think we're no longer quorate anyway? [17:19] So how about we continue this application in the next available meeting? [17:20] In the meantime, fheimes should feel free to look at logs and/or docs IMHO. [17:20] My intention here is just to make sure you understand enough to not stop on others' toes or end up with mismatched expectations. [17:20] well, I am on vacation starting in August [17:20] soure [17:20] s/soure/sure [17:21] OK. Please identify a subsequent meeting that you're avaiable for, and put a date against your agenda item. [17:21] k, will do [17:22] Sorry we couldn't come to a conclusion in this meeting. [17:22] anyway, thx [17:22] As we're over, let's stop here, and leave the other agenda items for a subsequent meeting. [17:22] #endmeeting [17:22] Meeting ended at 17:22:30 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-07-25-16.06.moin.txt [17:24] genii: now, give me my coffee you lurker. :P [17:26] * genii slides teward a large mug of Aeropressed Parabolic Espresso Medium Roast [17:26] * genii sweeps up and washes out all the mugs