16:06 <rbasak> #startmeeting Developer Membership Board
16:06 <meetingology> Meeting started at 16:06:53 UTC.  The chair is rbasak.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
16:06 <meetingology> Available commands: action, commands, idea, info, link, nick
16:07 <rbasak> Let's just dive straight in to the applications as we'll be pushing for time anyway.
16:07 <rbasak> #topic Ubuntu Core Developer Applications
16:07 <rbasak> #subtopic Mattia Rizzolo
16:07 <rbasak> mapreri: o/ could you introduce your application please?
16:07 <rbasak> #link https://wiki.ubuntu.com/MattiaRizzolo/CoreDevApplication
16:08 <mapreri> 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 <rbasak> Your sponsorship miner suggests that in the past two years you've only made two uploads into Ubuntu. Is this accurate?
16:09 <mapreri> 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 <mapreri> that… inaccurate I believe
16:10 <mapreri> let me check
16:10 <mapreri> or well, who knows
16:10 <mapreri> I don't honestly keep track
16:10 <teward> *appears*
16:10 <teward> (sorry i was on a walk)
16:11 <mapreri> 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 <rbasak> 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 <mapreri> answer is that he kept saying he would have done it "in time for the meeting" but then never did :3
16:14 <mapreri> btw
16:14 <mapreri> "only made two uploads into Ubuntu" - those are the sponsored ones
16:14 <mapreri> so I suspect only 2 in main, however including universe I count 66 uploads
16:14 <mapreri> and main for which I have PPU (say, devscripts)
16:14 <rbasak> MOre are listed here, but it folds entries for the same package/series IIRC: https://launchpad.net/~mapreri/+uploaded-packages
16:15 <mapreri> udd=> select source, version, date from ubuntu_upload_history where changed_by_name = 'Mattia Rizzolo' and  date >= '2021-01-01';
16:18 <rbasak> I have some further questions, but before I continue, does anyone else have questions for mapreri?
16:18 <bdmurray> mapreri: Could you remind up what packages you have PPU for?
16:18 <bdmurray> s/up/us/
16:20 <seb128> (I don't)
16:20 <mapreri> bdmurray: afaik devscripts, strip-nondetermism, inkscape, pbuilder, libroffice-dictionaries
16:20 <mapreri> not sure if I have more tbh, but I'm pretty sure I've got those
16:21 <rbasak> 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 <mapreri> 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 <rbasak> 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 <mapreri> (the latter of which pretty much never applies for main packages, fwiw…)
16:27 <mapreri> 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 <mapreri> 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 <mapreri> (though it of course wouldn't be bad to stage those things properly too, sure)
16:28 <rbasak> 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 <mapreri> 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 <mapreri> from my POV, the FFe process is also a kind of peer review
16:30 <rbasak> OK, thanks. I think I'm done with my questions.
16:30 <rbasak> Does anyone else have anything else they'd like to raise?
16:31 <mapreri> 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 <mapreri> (as an example)
16:31 <mapreri> 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 <rbasak> #vote Grant mapreri core dev
16:33 <meetingology> Please vote on: Grant mapreri core dev
16:33 <meetingology> 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 <seb128> +1
16:34 <meetingology> +1 received from seb128
16:35 <bdmurray> +1
16:35 <meetingology> +1 received from bdmurray
16:36 <rbasak> My vote/reasoning is a bit long...
16:38 <rbasak> 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 <rbasak> seems weak given the rest of this application.
16:38 <rbasak> 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 <rbasak> 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 <rbasak> 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 <rbasak> +1
16:38 <meetingology> +1 received from rbasak
16:38 <teward> +1
16:38 <meetingology> +1 received from teward
16:39 <rbasak> You also have proxy +2 from Lucas and Utkarsh
16:39 <rbasak> #endvote
16:39 <meetingology> Voting ended on: Grant mapreri core dev
16:39 <meetingology> Votes for: 4, Votes against: 0, Abstentions: 0
16:39 <meetingology> Motion carried
16:39 <mapreri> I'm actually very happy to read those words from you, rbasak !
16:39 <rbasak> Congrats!
16:39 <seb128> congrats!
16:39 <seb128> and sorry I need to drop now
16:39 <mapreri> Thank you, everybody!
16:40 <rbasak> Could somebody volunteer for https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_a_successful_application please?
16:40 <fheimes> mapreri Congrats!
16:40 <teward> rbasak: depends, can i get a coffee first?  :P
16:41 <rbasak> Sure, thanks :)
16:41 <rbasak> #action teward to announce mapreri's successful application
16:41 * meetingology teward to announce mapreri's successful application
16:41 <LocutusOfBorg> rbasak, thanks for the exception
16:41 <rbasak> #action teward to make ACL changes for mapreri's core dev status
16:41 * meetingology teward to make ACL changes for mapreri's core dev status
16:41 <teward> ... after coffee run :P
16:41 <LocutusOfBorg> 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 <rbasak> #subtopic Frank Heimes
16:42 <mapreri> I'm pretty sure he was upset I picked this date as we were at debconf and today is a travel day
16:42 <mapreri> also me I'm going afk now and fall asleep!
16:42 <rbasak> fheimes: hello!
16:42 <mapreri> thank you again, and o/
16:42 <fheimes> Hello !
16:42 <rbasak> #link https://wiki.ubuntu.com/FrankHeimes/MOTU
16:42 <mapreri> (good luck fheimes !)
16:42 <fheimes> thx
16:43 <teward> 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 <fheimes> I've updated the wiki page a bit
16:43 <fheimes> please also look for the section: "Updates since ..."
16:43 <teward> or at the very least i've reviewed / opinioned on your stuff
16:43 <fheimes> yes, that could well be ...
16:44 * fheimes is often working on more "alien" architectures ...
16:45 <teward> 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 <fheimes> sure (any time)
16:46 <rbasak> fheimes: feel free to introduce your application.
16:46 <rbasak> Does anyone have questions for fheimes please?
16:46 <rbasak> We don't have very long :-/
16:46 <fheimes> Sure - First of all I apologize to not having sent out the ann. of the appl. earlier - but it's out now.
16:46 <fheimes> 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 <fheimes> So I'm working with partners, especially with a specific one.
16:47 <fheimes> The areas and topics I'm working on are mainly the s390x and ppc64el projects, but not limited to these.
16:47 <fheimes> 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 <fheimes> 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 <rbasak> Do you have PPU for anything at the moment?
16:48 <fheimes> Since Jan I spent some more focus on merge and syncs (like you can see on the MOTU wiki page).
16:49 <fheimes> No I do not have PPU rights (but thought about them)
16:49 <bdmurray> fheimes: Do you have a rough estimate of the ratio of main to universe packages you work on for a specific partner?
16:50 <fheimes> well - 20- to 25% main, the rest universe ?!   (not talking about kernel)
16:50 <rbasak> 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 <fheimes> but a really rough est. ...
16:52 <fheimes> so after feature freeze / debian import freeze,  this would be a FFe (feature freeze exception) - I worked on some
16:52 <fheimes> I would go to the wiki and (re-)read about the possible exceptions
16:52 <fheimes> a new package would be acceptable in this case if it is for example a "bug fix only" release
16:52 <rbasak> How would you determine if it's a "bug fix only" release or not?
16:53 <fheimes> 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 <fheimes> if these all all fixes, then I would consider this as bug fix only release
16:54 <fheimes> I have btw. worked on such a case in prep for 22.04 -  it was openssh-ibmca
16:54 <rbasak> OK, thanks
16:55 <rbasak> Do you understand your endorsement feedback about pcre2?
16:55 <fheimes> other "exceptions" are for example  high-priority cases
16:55 <rbasak> For example, in that case, with the benefit of hindsight, what specifically would have alerted you to the issue before upload?
16:55 <fheimes> about the transition? yes I think so
16:56 <fheimes> it is important to know what is all triggered by an upload (especially a library upload)
16:56 <fheimes> therefor I was keen on working on the libica3 to 4 migration (again in prep for 22.04)
16:56 <fheimes> since this triggered a transition ...
16:57 <fheimes> 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 <rbasak> 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 <fheimes> (but let me double-check the endorsement again, so that I didn't missed anything ...)
16:58 <rbasak> 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 <fheimes> I would look at the reverse dependencies (of the source package), like:
16:58 <fheimes> reverse-depends -a source src:libica
16:58 <fheimes> (I see)
16:59 <fheimes> but there are more ways to figure out reverse depndencies - but I think this is a good way ...
16:59 <rbasak> 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 <fheimes> if I get some rev. deps listed
17:00 <fheimes> I re-build these based on the package that is in discussion
17:01 <fheimes> well, there are several things:
17:01 <fheimes> first I always look for and ask is this is upstream
17:01 <fheimes> 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 <fheimes> 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 <rbasak> What about ongoing maintenance? Are you prepared to maintain a patch in universe indefinitely if you upload or sponsor it?
17:03 <fheimes> esp. in case of an SRU, rules are a bit more strict
17:03 <fheimes> hence one also needs oto fill out the  SRU template and create a justification
17:05 <fheimes> well, in case of my particular partner there is an agreement in place that it will be maintained
17:05 <fheimes> but of course nobody wants to maintain it (oot) for ever
17:05 <fheimes> 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 <fheimes> that is btw. what I did with tigervnc
17:05 <rbasak> OK, thanks. Next question: if a package you uploaded is "stuck in proposed", what do you need to do next?
17:07 <fheimes> first of all I try to identify reasons why this is the case
17:07 <fheimes> (could be outstanding verifications)
17:07 <fheimes> where I may work on myself, or with the partner (in case of special hw needs)
17:07 <fheimes> if I don't see and find a reason I would probably ask - one from SRU team
17:07 <bdmurray> What if a package was stuck in -proposed for the development release?
17:09 <fheimes> well, after beta and rc things become more restrictive, even for a development release and I may turn it into a FFe
17:09 <fheimes> but if a package is in -proposed - even prior to the FF it should still be eligible for an update
17:10 <fheimes> and for the development release, the SRU team is no longer responsible
17:11 <fheimes> (in this case I would probably ask on the archive admins)
17:12 <rbasak> I'm having some doubts in your understanding of some of the details here. Both in proposed migration, and in identifying transitions.
17:12 <fheimes> well, if this is not what you wanted to hear, can you please be a bit more specific?
17:13 <rbasak> 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 <rbasak> Yes of course I will go into details.
17:13 <bdmurray> Have you done any +1 maintenance?
17:14 <fheimes> 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 <bdmurray> If not I think a couple of shifts would provide valuable experience in this area.
17:14 <rbasak> Would PPU for some specific packages be useful to you if your MOTU application is not successful today?
17:14 <fheimes> no, I (actually our team) doesn't do +1 maintenance
17:14 <rbasak> 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 <fheimes> I think so - but this would of course limit me to these ...
17:15 <rbasak> 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 <fheimes> 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 <fheimes> yes, I know that page
17:17 <fheimes> and also know update excuses
17:17 <fheimes> e.g. blockers, failed tests failed dependencies
17:17 <rbasak> 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 <teward> 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 <teward> (unrelated: redis-server defaults are evil)
17:19 <rbasak> Seb had to leave and I think we're no longer quorate anyway?
17:19 <rbasak> So how about we continue this application in the next available meeting?
17:20 <rbasak> In the meantime, fheimes should feel free to look at logs and/or docs IMHO.
17:20 <rbasak> 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 <fheimes> well, I am on vacation starting in August
17:20 <fheimes> soure
17:20 <fheimes> s/soure/sure
17:21 <rbasak> OK. Please identify a subsequent meeting that you're avaiable for, and put a date against your agenda item.
17:21 <fheimes> k, will do
17:22 <rbasak> Sorry we couldn't come to a conclusion in this meeting.
17:22 <fheimes> anyway, thx
17:22 <rbasak> As we're over, let's stop here, and leave the other agenda items for a subsequent meeting.
17:22 <rbasak> #endmeeting