16:01 #startmeeting Developer Membership Board 16:01 Meeting started at 16:01:52 UTC. The chair is utkarsh2102. Information about MeetBot at https://wiki.ubuntu.com/meetingology 16:01 Available commands: action, commands, idea, info, link, nick 16:01 o/ 16:02 we have today's agenda here: https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda 16:02 #link https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda 16:03 skipping through the first few tasks, I guess 16:03 I'm somewhat preoccupied with an issue in my aera 16:03 I think the vote for Alex from the previous DMB meeting is finished, someone needs to announce the failed result. Should we get some action items to handle the unsuccessful application? 16:03 and directly proceeding to MOTU applications (we have quite some other things to discuss as well!) 16:04 #topic MOTU Applications 16:04 #subtopic Frank Heimes 16:04 o/ 16:04 I think we still lack the quorum for that one - it's been a while now. 16:04 where does the vote stand currently on the ML? 16:04 since it was moved to ML 16:05 bdmurray's vote is all that's left, last time I checked. 16:05 bdmurray: ^ 16:05 ack 16:06 3 +1s, 2 -1s, 2 +0s 16:06 bdmurray: your vote is going to be the deciding thing here 16:06 should I move on considering bdmurray will vote soon and we can then wrap this up? 16:07 yes lets move on 16:07 yes move on, we'll hadnle any ML-moved items on the ML 16:07 thanks! 16:07 #topic Alexandre Ghiti 16:07 3 -1s, 2 +0s 16:07 even though sil2100 and bdmurray haven't voted yet, it's clear that it's -1 overall 16:07 As mentioned, this has enough votes, sadly 16:07 Yeah 16:07 so I'll wrap that up 16:07 Thanks! 16:08 moving on.. 16:08 #action utkarsh2102 to take care of Alexandre Ghiti's application. 16:08 * meetingology utkarsh2102 to take care of Alexandre Ghiti's application. 16:08 #subtopic Heinrich Schuchardt 16:08 #link: https://wiki.ubuntu.com/HeinrichSchuchardt/MOTUApplication 16:09 xypron: hellu! please introduce yourself! \o 16:09 Nice to meet you. I am living in Leverkusen, Germany. I am working in the Foundations team as RISC-V lead engineer. This and +1 maintenance requires touching packages in Universe. I am also the maintainer of the UEFI implementation in U-Boot. 16:09 o/ 16:09 Were you expecting any more endorsements? 16:09 no 16:09 https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*Heinrich*&sponsoree_search=name suggests a wide range of sponsors. 16:09 I got the ones I asked for 16:09 What are their opinions on your MOTU application? 16:11 My understanding is that I have gathered a good bunch of experience in packaging. And at least from my team I had the feeling that my colleauges were ok with me going forward to apploy. 16:11 Your upload history certainly looks good and wide ranging. 16:12 I find that very clever, funny, and interesting that 6 out of 7 DMB members have sponsored something for you. :) 16:12 *is the only one who hasn't* 16:12 That was not my intent :) 16:12 I did not formally endorse Heinrich's application, but whenever sponsoring his packages, I can't remember having any issues with the provided packaging! 16:13 teward: you have :) 16:13 rbasak: hasn't 16:13 i have? 16:13 oh 16:13 wait why don't i show up in the list :| 16:13 sbsigntool 16:13 oh there i am >.< 16:13 *goes and facedesks* 16:13 0.9.4-2ubuntu1 to Impish 16:13 you do show up there 16:13 and squid :) 16:14 I do feel quite strongly that I'd like to see endorsements from a representative sample of sponsored uploads though. 16:14 in fact twice 16:14 yes! 16:15 rbasak: Is that something the candidate can control? 16:15 I can endorse xypron packaging knowledge for sure. As said, I never had any issues with any of the packages he provided, as far as I can remember 16:16 I'm not suggesting requiring endorsements from 100% of sponsors. But I think it's reasonable to consider it an issue if it's nearly the opposite. 16:16 Process-wise, I'd like to ask some questions during the question phase, but not sure 16:17 And for Canonical employee applicants where the sponsors are primarily Canonical employees, I don't think it's unreasonable at all. 16:17 rbasak: it's hard to get endorsements right now, that is a sad fact. I've heard it from multiple applicants that it's hard for them to get endorsement comments on their applicaitions 16:17 OTOH, the other reason people may not be comfortable endorsing are if they aren't confident an applicant is ready. It's not possible to tell the difference. 16:17 Generally the rule of thumb so far was 2+ endorsements for MOTU, 3+ for core-dev 16:18 So I would feel bad to suddenly require something from our applicants if we weren't explicit about this 16:18 If we count sil2100 then we are at 3 so can consider that "enough" and move on? 16:18 I'm sure xypron would push harder for endorsements if he knew he'd need more 16:18 I agree 16:18 rbasak: then it should be made clear that all former sponsors should be pinged. I only pinged sil2100 seb128 and ginggs. 16:19 Yeah, I didn't put anything due to time constraints, so the main thing that always makes getting endorsements so difficult 16:20 I also did thought it should be recent sponsors as of course packaging has a learning curve. 16:20 * utkarsh2102 wonders if he can get his endorsement on joining the release team but then also wonders now is not the time to joke :) 16:21 I agree to move on, 2 (+ sil2100) is good enough for now. rbasak: please consider this making an explicit thing if you feel strongly about this but are you okay in moving on for now? 16:23 Oh sure, please don't block on me. 16:23 It's going to influence my personal opinion in my vote though. 16:23 fair 16:23 * utkarsh2102 opens the floor for questions 16:23 sil2100: go, go, go 16:24 and others, too 16:25 xypron: so I'd like you to tell me a bit more about freezes in Ubuntu. What kind of Ubuntu freezes should one expect for the development release (like kinetic)? What types of freezes do we have and what should/should not be done after one? 16:25 xypron: have you handled a complex merge? With say more than five differences against Debian? 16:25 First of all kernel has separate freeze dates from rest of the distro. 16:26 Before a release we have a soft freeze were we need feature freeze exceptions and then hard freeze whereafter we only fix grave bugs. 16:28 Details can be found in https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess 16:28 Ok that page lists more freeze events. 16:29 xypron: there is more, but you listed the important ones 16:29 I think rbasak had a question above ^ 16:30 The most complex thing was getting RISC-V support into GRUB. 16:30 Upstream was reviewing patches for the LoadFile2 protocol and then for RISC-V. All not merged upstream and not in Debian. 16:31 The disucussion with our maintainer resulted in that he only wanted changed behavior in riscv64 not in arm or arm64 which were touched by the upstream patches. 16:31 This was unfortunate as our arm64 code was and still is questionable to not say buggy. 16:31 When I say merge I mean the process of updating an Ubuntu package that has a delta with an update in Debian 16:31 Are we talking about the same thing? 16:32 Yes there were packages that had multiple ubuntu patches that are not in Debian. GRUB was one of them. 16:32 Do you have a link of you doing that merge, please? 16:33 GRUB goes through git. Let me look for the URL 16:33 https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu 16:34 rbasak: probably meant a link to your MP or equivalent 16:35 not the general git LP page of the package, hehe 16:35 Or just which upload you had sponsored. 16:35 Looking at that link, it doesn't look like you did the package merge for 2.06-2ubuntu1. Which one did you do? 16:38 Let me just search my bug list for updates 16:40 Sorry there were some packages were to fix autopkgtests I used a new DEbian package but I don't remember which. 16:40 meanwhile I'll put my question here, please complete the one going on until rbasak is happy :) 16:40 https://bugs.launchpad.net/ubuntu/+source/findutils/+bug/1973788 is merge form debian 16:40 q: d'you actively send delta to Debian? if so, how? can we have some links? 16:40 yes. 16:41 cf: https://launchpad.net/ubuntu/+source/r-cran-openssl/1.4.6+dfsg-1ubuntu1 -> was it forwarded? I can't find so, only see a sync later (which is good enough here but still) 16:41 There are two ways: just send our bug to debian via submit to debian or 16:41 via salsa 16:42 For some problems I started creating merge request in salsa. 16:42 d'you have a list of such bugs or something? 16:42 it should be fairly easy to generate though 16:43 follow-up q: how d'you track a package where you add a delta? 16:43 https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;submitter=Schuchardt should find my submitted bugs 16:43 I could add myself to the bug CC. 16:43 "No reports found!" 16:43 merge-o-matic will bring up future changes 16:46 "could"? :) 16:46 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005802 is one of the bug reports I created. So no clue why the search did not work 16:46 how do you do them so far? 16:48 any more questions meahwhile? 16:48 I have been using submittodebian. But I may have missed to do it in some cases. 16:48 :( 16:49 Where would you go to find out the feature freeze date for the next release after Kinetic, once it's set by the release team? 16:51 It should be on the developers mailing list. But also in https://launchpad/ubuntu/ 16:51 https://discourse.ubuntu.com/t/l-release-schedule/27284 16:52 OK, thanks. 16:52 No more questions. 16:52 f.y.i. https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;submitter=heinrich.schuchardt%40canonical.com 16:53 thanks ginggs 16:53 xypron: https://wiki.ubuntu.com/LightweightLobster/ReleaseSchedule -> should be a redirect to the discourse page. :) 16:54 ofc, if the release name indeed is "LightweightLobster" :) 16:54 good to know 16:54 sil2100, bdmurray, teward: any more questions? 16:54 6 minutes until EOM 16:54 nope 16:54 No questions here 16:56 moving on in 3 16:56 2 16:56 1 16:56 #vote Heinrich Schuchardt to get MOTU rights 16:56 Please vote on: Heinrich Schuchardt to get MOTU rights 16:56 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:56 -1 16:56 -1 received from rbasak 16:57 (reasons to follow) 16:57 #voters rbasak sil2100 bdmurray teward utkarsh2102 16:57 Current voters: bdmurray, rbasak, sil2100, teward, utkarsh2102 16:58 +1 16:58 +1 received from bdmurray 16:59 +0 while i feel packaging skills and understanding of process are generally present, I wish there were more endorsements before I can fully give a 100% support for unrestricted MOTU rights. 16:59 +0 while i feel packaging skills and understanding of process are generally present, I wish there were more endorsements before I can fully give a 100% support for unrestricted MOTU rights. received from teward 16:59 +0 I have no doubts as for Heinrich's packaging skill and skill as an engineer, and I love that Heinrich also learns quick and can gather the needed information fast in case it's needed. But the questioning phase showed that I think he needs a bit more knowledge regarding the non-technical processes. So I'd say asking around those to get a better feeling of the formalities 16:59 +0 I have no doubts as for Heinrich's packaging skill and skill as an engineer, and I love that Heinrich also learns quick and can gather the needed information fast in case it's needed. But the questioning phase showed that I think he needs a bit more knowledge regarding the non-technical processes. So I'd say asking around those to get a better feeling of the formalities received from sil2100 17:00 I know we shouldn't be doing +0 more often but.. 17:00 +0; reasons to follow.. 17:00 +0; reasons to follow.. received from utkarsh2102 17:01 Thank you for your work in Ubuntu! Your sponsored upload history looks good. But, for example, package merges in Ubuntu aren't necessarily trivial, and I could only find trivial ones in the sponsorship miner. If you're going to be MOTU, I'd like to ensure that you can handle a complex one unsupervised, which is rather different that just relying on merge-o-matic. But I couldn't find an example of 17:01 I really was ready to +1 but the questioning phase gave me second thoughts. I am sure Heinrich is almost there but I don't have solid confidence in being a +1 now. 17:01 you having done one. 17:01 I also rely heavily on endorsements. I appreciate this is tough for you since it appears to be mainly down to your colleagues. This is therefore more on the team, not on you. But I'm not comfortable accepting an apparent lack of endorsements as it's impossible to tell the difference between most of your sponsoring colleagues not being confident you're ready and thus not endorsing, and them just not 17:01 getting round to it. 17:01 If you were a non-Canonical applicant or your sponsors weren't primarily Canonical employees, I'd try to get more involved and see how I could help and what compromises would be appropriate to make. But for a Canonical Foundations team member with primarily colleagues sponsoring, I think it's really on your team, your mentors and perhaps your team manager to sort this out. 17:01 Keep in mind that my bar is where it is for MOTU because the permission is to upload to the archive _unsupervised_. The supervised work you have been doing is good; I'd just like to see better coverage in terms of endorsements from your sponsoring colleagues, and in the Ubuntu-development-process-complexity in your experience, before voting to give you unsupervised access. To be clear, I don't 17:01 think there's any question about your technical ability or technical-complexity here, IYSWIM. Please keep up the good work! 17:02 wow, that's super detailed. I like it! 17:02 Thanks for reviewing and pointing to future learning. 17:02 #endvote 17:02 Voting ended on: Heinrich Schuchardt to get MOTU rights 17:02 Votes for: 1, Votes against: 1, Abstentions: 3 17:02 Motion carried 17:02 I'm sorry we couldn't approve your application today. 17:03 indeed^ :( 17:03 I think maybe we need to address this further up the chain - in how mentoring for this process is being delivered by your team. 17:03 but I really encourage you to apply, hopefully by the end of the year? 17:03 Inside Canonical I'm making some efforts on addressing this. 17:04 I should sit down with sil2100. 17:04 xypron: I know you're in ~Foundations and you have absolutely the best folks around to help and assist. But should you need anything else, please don't hesitate to reach out to me either. 17:04 I'll be happy to help, work, and assist. 17:04 Thanks a lot. 17:05 we're a bit overtime 17:05 ok! 17:05 but we have something important 17:05 #action utkarsh2102 to take care of Heinrich's application 17:05 * meetingology utkarsh2102 to take care of Heinrich's application 17:05 #topic AOB 17:06 #subtopic: Consider reinstatement for Scott Moser 17:06 #link https://lists.ubuntu.com/archives/devel-permissions/2022-October/002056.html) 17:06 Ah yes, thanks. 17:06 (failed to successfully remove the ")" character but let's go 17:06 bah 17:06 anyway, how do we stand there 17:06 Scott is a former colleague of mine, so I know him quite well (although we're less in touch nowadays). 17:07 should we discuss or just vote? 17:07 reinstatement for core dev correct? 17:07 In the past, when someone has asked for a reinstatement after a long time, the DMB wanted to know the reasons for their departure, because if it was political or emotional, they might not be comfortable in reinstating them without some further thought. 17:07 bdmurray has some discussion to do, I guess? 17:07 sil2100 and rbasak was +1 17:07 That's why we didn't just automatically reinstate Scott in this case. 17:07 s/was/were/ 17:08 I'm comfortable with a +1 here because I don't think that concern applies in Scott's case, but I agree with the process that it's something we should consider before approving (but it so happens that I also approve). 17:09 IIRC his membership had expired for more than a year which I find worrisome in that he may not be familiar with current processes / best practices 17:10 bdmurray: I accept that might be an issue, but it's also an issue with core devs who haven't uploaded in many years but continue to renew their memberships of the team. It seems odd to allow them to continue, but deny Scott because of a missed email. 17:11 If that's still a concern, then rather than denying requests for reinstatement, we should require removal for inactivity or similar. 17:11 Notably Scott is still "around" in the sense that he's still in touch. 17:11 But I think there are core devs who most definitely are not. 17:14 I don't want to waste anyone's time here but we should really conclude what we want to do 17:14 or at least reach out to Scott and continue there 17:15 I'd be sad if there were no outcome (which is what it looks like) 17:15 bdmurray: if you don't want to approve Scott's reinstatement, then what do you want to happen instead? 17:15 I'm a +1, to be fair. Mostly because of what rbasak stated. I'm happy to see more community people around and active. I REALLYYYYYY LIKE IT. 17:16 teward: opinions? 17:17 rbasak: I see your point and think approving him is fine but I think the policy here should be reevaluated. 17:18 cool! 17:18 can someone work on the policy bit? 17:18 I'll put this in the Agenda and it's up for grabs 17:18 #action utkarsh2102 to approve Scott and mention the same 17:18 * meetingology utkarsh2102 to approve Scott and mention the same 17:18 (reinstate not approve but oh well) 17:18 thanks, all! 17:19 #endmeeting