== Meeting information == * #ubuntu-meeting: Developer Membership Board meeting, started by utkarsh2102, 29 Apr at 16:03 — 17:11 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-04-29-16.03.log.html == Meeting summary == * ''LINK:'' https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda (utkarsh2102, 16:04) === Core Dev Applications === Discussion started by utkarsh2102 at 16:04. * '''Amin Bandali''' (utkarsh2102, 16:05) * ''LINK:'' https://wiki.ubuntu.com/bandali/core-dev-application (utkarsh2102, 16:05) * ''VOTE:'' Amin Bandali to get Ubuntu Core Dev rights (Denied) (utkarsh2102, 17:07) * ''ACTION:'' Utkarsh to send out a follow-up mail on the ML (utkarsh2102, 17:10) == Vote results == * [[https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-04-29-16.03.log.html#129|Amin Bandali to get Ubuntu Core Dev rights]] * Motion denied (For: 0, Against: 4, Abstained: 0) * Voters: rbasak, teward, sil2100, utkarsh2102 == People present (lines said) == * utkarsh2102 (53) * bandali (48) * rbasak (36) * teward (13) * meetingology (12) * sil2100 (6) == Full log == 16:03 #startmeeting Developer Membership Board 16:03 Meeting started at 16:03:57 UTC. The chair is utkarsh2102. Information about MeetBot at https://wiki.ubuntu.com/meetingology 16:03 Available commands: action, commands, idea, info, link, nick 16:03 Reading up the backlog 16:04 #link https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda 16:04 I'll head straight to the applications o/ 16:04 #topic Core Dev Applications 16:05 #subtopic Amin Bandali 16:05 #link https://wiki.ubuntu.com/bandali/core-dev-application 16:05 bandali: hello! can you please introduce yourself? 16:05 meanwhile we all go through your application page? 16:05 hi utkarsh2102 :) sure 16:07 i'm Amin Bandali, and i've been part of Canonical's Ubuntu Desktop team since Nov 2022. i'm primarily the maintainer of Ubuntu's Firefox packages, but i also work on various other aspects of the Ubuntu Desktop, and i've also worked on other areas of Ubuntu in general, both via my kind sponsors and indirectly as a Debian Developer 16:07 Hi! 16:07 hi! o/ 16:07 " Becoming a core-dev would allow me to upload all kinds of desktop-related packages across the Ubuntu archive, not just the subset I have access to as a member of ~ubuntu-desktop (which excludes most packages in the desktop-core set)." 16:08 As above, I'm puzzled by this. Why aren't desktop-related packages that you need to upload as part of desktop work already the ubuntu-desktop packageset? 16:08 (maybe not really a question for you) 16:08 I ask because if we fixed that, surely that would help more people than just you? 16:09 Perhaps there are some packages that shouldn't belong in ubuntu-desktop for which you getting core dev privileges would help, but I'm unclear on what those are. 16:09 also, I note that there are endorsements from people who are not Ubuntu members/MOTU/core dev. Can they still endorse? I'd expect them to be in the "Comments" section. 16:09 right, that's a great question but unfortunately i don't have the historical background (i wish Seb was here today). but i know it goes back at least 4 years, and most likely many more years before that 16:09 i have a followup on that, why do you need coredev if instead you could apply for the specific packagesets 16:09 (even if we didnt consolidate all the desktop pkgsets today) 16:09 Could you perhaps elaborate on exactly which packages you would like to upload, and which of those packages you have had sponsored, that do not belong in the ubuntu-desktop packageset? 16:09 if so, then only two core-devs which are both in ~Desktop. Are there people who you've worked outside ~Desktop? 16:10 i'm applying for core-dev in part because i don't *only* work on desktop packages 16:11 i don't *only* work on desktop packages> OK - could you elaborate then please on exactly which packages we're talking about? 16:12 being a DD, i work on packages across the Debian archives (e.g. i maintain jami, opendht, restinio, etc.) 16:12 i believe there a number of exampels of non-desktop packages i've worked on on my application page, if you search for 'non-desktop' 16:12 OK but I don't see any sponsored uploads of those packages into Ubuntu. 16:13 ^^ that 16:13 how about poppler? 16:13 We should certainly consider PPU for the packages that you maintain in Debian 16:14 i also do +1 rotations every now and again, and being able to upload those directly would be great 16:15 For a core dev application, I'd like to start by seeing your track record of sponsorship in Ubuntu for the packages that you are looking to upload. To be clear, I'm not saying that there's a hard requirement to have these, but I'd like to understand where you are and that's usually my starting point, and I'm struggling to identify the subset of your sponsored uploads that relate to this application. 16:15 I was wondering if a path like packageset -> MOTU -> core-dev would be good. So essentially, MOTU being the next target? 16:15 it so happens that for my last +1 shift i was able to do all of my work directly in Debian, but being able to do that work directly in Ubuntu would be nice 16:15 re: +1 work^ 16:16 i did initially consider MOTU first, but thought it might be good to skip directly to core-dev since i've worked on a number of non-desktop main packages like poppler etc. that aren't in universe and so not addressed by motu 16:17 and thought that my background and experience as a DD would have provided me with the skills to aim directly for core-dev 16:17 I realise that poppler isn't strictly desktop since I suppose it can be used usefully in a server environment, but it does still feel desktop-y. Has it been considered for the ubuntu-desktop packageset? 16:18 not that i know of, i'd defer to Seb to clarify that 16:19 (also, to be clear, this is the part of the page i was referring to earlier: https://wiki.ubuntu.com/bandali/core-dev-application#non-desktop ) 16:20 Did you take that from the sponsorship miner / udd? I'm looking the miner results at https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=*bandali*&sponsoree_search=name and it seems a bit messed up :-( 16:21 err yes i think so 16:21 I was gonna get to that, too :) 16:21 there seems to be a mismatch 16:21 yeah e.g. some of that aren't SRUs 16:21 a lot of those uploads are uploads to Debian 16:21 and a sync here 16:22 that's why some won't show up in UDD 16:22 sorry i probably should've cleaned that up beforehand. in my defence i wasn't sure if there would be a meeting today.. 16:23 bandali: it's always best to **assume there will be a meeting** if you've placed yourself in the agenda 16:23 because otherwise you arrive here unprepared 16:23 teward, that's what i assumed the last times it didn't happen :) 16:23 but ack 16:25 bandali: I see almost all uploads by Jeremy and some by Seb. Whilst that's not a problem, I am wondering if you have worked with core-devs outside ~Desktop? 16:25 Do you have any SRU experience for regular bugfixes? 16:25 I only see https://launchpad.net/ubuntu/+source/gtk4/4.12.3+ds-1ubuntu0.1 which looks like an upstream point release. Are there any other SRUs you've had sponsored? 16:26 utkarsh2102, yes indeed, just about all my uploads to Ubuntu have been sponsored by Jeremy and Seb 16:26 rbasak, i believe i had several more. lemme see if i can find them quickly 16:28 bandali: related to rbasak's question: what do you need to consider when preparing for an SRU upload? What can be uploaded as an SRU, what is the process and how to make it land in a stable series? 16:28 and on that note, I had a question.What if a package X is on version 1.2.3-1 in Focal and 1.2.4-1 in Mantic, Jammy, Noble, and devel (Oracular now). And there's a bug you'd like to fix for X at least for Focal, what will be the next steps? 16:28 rbasak, e.g. there's this nautilus one https://launchpad.net/ubuntu/+source/nautilus/1:42.6-0ubuntu1 but as a component of GNOME core, it has a micro-release exception 16:29 I'm really looking for "regular" ones please 16:30 (since they exercise the SRU process much more compleely - do you have experience of doing that?) 16:30 I have more questions, but I'll let you get the above ones squared away first :) 16:30 rbasak, i recall doing some but i'm afraid i don't have a link handy at this moment. i'll let you know if i can find though 16:30 sil2100, typing my answer to your question now 16:30 :( 16:30 Thank you! :) 16:32 sil2100, generally speaking, SRUs should only contain bug fixes and no new features. the procedure is described on https://wiki.ubuntu.com/StableReleaseUpdates, including a sample template for the accompanying bug that needs to be filed on LP to explain the rationale for the SRU, its potential impact on users, and the bug(s) it aims to fix and how that can be validated (that it indeed fixes though 16:32 bugs) 16:32 (also including a test plan for testing and validation of the fix, of course) 16:33 utkarsh2102, typing an answer to your question now 16:35 utkarsh2102, generally the fix should also be prepared for all affected later Ubuntu releases as well, so that upgrading to newer releases wouldn't cause a regression again 16:35 bandali: okay, thanks, what versions would you use for each releases, then? 16:37 utkarsh2102, the versions of X would have to be crafted in a way to ensure that they are in increasing order from one Ubuntu release to the next, so that apt would correctly pick it up as an upgrade 16:37 yes, can you give me exact versions please? 16:37 bandali: thanks. And once the SRU gets accepted into -proposed, what does the uploader need to do? What are their responsibilities? When will the update be made avilable to the users? 16:38 utkarsh2102, e.g. 1.2.3-1ubuntu1 in focal, perhaps 1.2.3-2ubuntu1 in jammy, and 1.2.4-1ubuntu in mantic 16:40 sil2100, the uploader would then do validation on the -proposed upload to verify that the indeed fixes all the bugs it claims to have fixed and introduced no regressions. then mark the bug as verification-done-$rel 16:41 I am afraid that's not quite correct :( 16:41 bandali: see https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation :) 16:42 bandali: the uploader would then do validation> specifically, what would be considered an acceptable level of validation, and what would not? At that stage in the process, how could the uploader be sure that the validation they're performing will be considered acceptable by the SRU team? 16:42 utkarsh2102, ack 16:42 sil2100, once verified, the upload would then be released to users via -updates, potentially with phasing and monitoring that e.g. there are indeed no increased crash rates 16:44 rbasak, the details would vary from one case to the next, but i believe at minimum the uploader would need to exercise the agreed upon test plan for the package being updated 16:45 OK. And if, after an SRU you prepared is released, you discover that it resulted in a serious regression, what should you do? 16:45 re: +1 maint: once you've uploaded a package to the devel release, is there something else you should be doing? 16:47 rbasak, if it's still in phasing, the phasing should be halted and a new SRU with the fix prepared. if it's ineed a serious/critical regression, one would need to prepare a new stop-gap upload effectively rolling the package back to previous version, while another upload could be prepared 16:48 bandali: OK, but what's the process to arrange these things? 16:49 utkarsh2102, generally, i'd check if the devel upload contains fixes potentially relevant to existing stable releases and if so, prepare an SRU. i'd also check if my fix for Ubuntu could be applied upstream in Debian, or perhaps even better, directly to the main upstream project, and forward my patch(es) to them accordingly. if that's not quite the answer you were looking for, would you please 16:49 clarify? 16:51 rbasak, as in, e.g. what version to use for an upload of the previous working version? 16:53 bandali: sorry no that's not what I'm asking. Imagine you've just heard about this serious regression and Jeremy and Seb are unavailable. As a core dev, your team is looking to you to sort things out. What's the established process to alert the SRU team? 16:54 You may understand that the SRU team will stop phasing and/or urgently review your revert upload, but how is it that you will get their attention to do this? 16:55 bandali: my question is limited to the devel release you may upload to, once the upload is done, where does it go? what next steps you might want to work on to ensure the entire work's done? 16:56 rbasak, for contacting the SRU team, i'd check https://wiki.ubuntu.com/StableReleaseUpdates#Contacting_the_SRU_team to see who is on rotation that day, and ping them in #ubuntu-release or directly to draw their attention to the matter 16:57 fyi guys I have a hard-stop in 3 minutes 16:58 okay, I'll start to push this faster 16:58 utkarsh2102, oh, thanks for the clarification. normally, the upload to devel would land immediately. but that won't be the case e.g. during one of the devel freezes (where the package would land in -proposed) or if the package is NEW 16:58 and would need to be manually reviewed and approved by an AA 16:58 I'm not sure we can conclude today :-( 16:59 rbasak: i don't think we can either, but feel free to continue the meeting 16:59 bandali: if I am not mistaken, the upload to devel don't just land to the -release pocket immediately. 16:59 just poke me when you need a vote 16:59 it goes to -proposed and then to -release subsequently 16:59 (I won't be able to do much else here at that point though, I already have my info I need for a vote) 17:00 utkarsh2102, oh? i thought they only went through -proposed e.g. during freezes, but sorry if i got that wrong 17:00 do you know what's the process for an upload to move from -proposed to -release 17:00 teward: if you have your vote ready, can I proxy that if we conclude in a bit? 17:00 you could perhaps DM me and I can comment on your behald 17:00 utkarsh2102: i'll just leave it in paste so you can say "please vote" with a ping to me and i'll hit enter 17:01 teward: works perfectly for me 17:01 not sure off top my head, i'm afraid. but i'd imagine a member of ubuntu-release would shepherd it through? 17:01 bandali: I am afraid not, it's the duty of the uploader to shepherd it 17:02 and only contact the release team when you've tried all the obvious things that are blocking the migration 17:02 OK I was somewhere between "more information would help me vote" and "I think we have some more adminstrative matters to resolve first". But I'm afraid your answers continue to give me concern and so I'm a hard -1 now, and I don't see any point in dragging this on further. 17:02 ack 17:02 ok, are we ready to vote in that case? 17:02 I've been writing up more specifics to give you some guidance on what to work on here. I'll continue doing that. I'll be a few minutes. 17:03 bandali: see https://wiki.ubuntu.com/ProposedMigration/. That's what I was looking for. 17:03 the first point "Migrating packages from -proposed to release" 17:03 anyway, sil2100: okay to vote? 17:03 Yes 17:03 utkarsh2102, ah, yes of course. sorry 17:04 #vote Amin Bandali to get Ubuntu Core Dev rights 17:04 Please vote on: Amin Bandali to get Ubuntu Core Dev rights 17:04 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') 17:04 -1 reasons to follow 17:04 -1 reasons to follow received from rbasak 17:04 -1 While I feel the development contributions are significant, I feel there is not enough knowledge about the various processes, requirements, etc. to properly give this individual unrestricted upload privileges. I encourage bandali to continue to review and learn the processes and do some uploads with extra sponsors and support and then at some point in the future apply again. 17:04 -1 While I feel the development contributions are significant, I feel there is not enough knowledge about the various processes, requirements, etc. to properly give this individual unrestricted upload privileges. I encourage bandali to continue to review and learn the processes and do some uploads with extra sponsors and support and then at some point in the future apply again. received from teward 17:04 *now devotes 98% attention to his day-job meeting with the bosses* 17:04 o/ 17:06 -1 There seems to be still a lot that bandali needs to learn about the Ubuntu upload process. Also, I'd like to see more SRU work + more varied sponsors, if possible 17:06 -1 There seems to be still a lot that bandali needs to learn about the Ubuntu upload process. Also, I'd like to see more SRU work + more varied sponsors, if possible received from sil2100 17:07 -1; whilst I am happy to see your involvement in the project and that you became a DD recently and that you've been doing great work, I think there are some Ubuntu specific processes to ramp up on - eg: SRU process, Proposed Migration, versioning to use when preparing SRUs, what happens when there's a regression 17:07 -1; whilst I am happy to see your involvement in the project and that you became a DD recently and that you've been doing great work, I think there are some Ubuntu specific processes to ramp up on - eg: SRU process, Proposed Migration, versioning to use when preparing SRUs, what happens when there's a regression received from utkarsh2102 17:07 (https://wiki.ubuntu.com/StableReleaseUpdates#Regressions - what probably rbasak was looking for). Anyway, I think it'd be helpful to work with a core-dev for a bit and get clarity on these processes and I'd also recommend getting more sponsorships from people outside ~Desktop. I'd also recommend going via MOTU, et al. This helps in inspiring some 17:07 confidence. 17:07 #endvote 17:07 Voting ended on: Amin Bandali to get Ubuntu Core Dev rights 17:07 Votes for: 0, Votes against: 4, Abstentions: 0 17:07 Motion denied 17:08 thanks all for your feedback and time 17:08 I am sorry that the vote didn't go in favor. But I think we have some good feedback to work through and apply once again once you and your sponsors think it's time again! o/ 17:08 I think Robie is still finishing up his feedback.. 17:08 Yes 17:09 bandali: don't hesitate in asking DMB for help if you're ever stuck or need some advice or review, et al. ML is the best way if you'd like to reach us. 17:10 I am also happy to help with some sponsorship provided my capacity! o/ 17:10 Here's some specifc feedback: 17:10 1) I'd like clarity on what exactly you're looking to unblock by getting core dev privileges, and then a clear track record of sponsorship for those specific things. Right now I'm very unclear on this and this hampers me from objectively considering your application. If you already have a suitable track record, there's no reason to wait - we can just see it as an admistrative matter to help us 17:10 better assess your existing application. 17:10 2) SRU knowledge and experience: I'd like to see experience of "regular" SRUs but so far I haven't seen anything apart from a couple of microrelease updates which follow a slightly different process. If you already have a suitable track record, there's no reason to wait - we can just see it as an admistrative matter to help us better assess your existing application. However, some of your 17:10 #action Utkarsh to send out a follow-up mail on the ML 17:10 * meetingology Utkarsh to send out a follow-up mail on the ML 17:10 SRU-relted answers missed the mark (eg. on versions and on flagging regressions). I feel that you should know these better - the answers are documented, or you improve your answers through experience. 17:10 3) Proposed migration. "i thought they only went through -proposed e.g. during freezes, but sorry if i got that wrong". This is indeed wrong, and I think a hard requirement for any core dev to understand. I'm also confused on how you achieved doing +1 maintenance without this knowledge. This suggests to me that you're assuming incorrect things about Ubuntu from your knowledge of Debian without 17:10 appreciating the key points on how our development processes differ. Please continue learning this. 17:10 4) That you worked on the poppler transition is good but looking at the actual uploads it's not clear to me if your contribution was driving the transition and that you understood the whole process, given your answer about proposed migration above. We didn't get to discussing this. 17:11 5) The above list isn't exhaustive - we ran out of time to discuss further. See https://wiki.ubuntu.com/RobieBasak/DMB/CoreDev for my opinion and what I expect you to know. 17:11 that's phenomenal advice, Robie. Thanks! o/ 17:11 thank you indeed for your detailed reply/feedback Robie, appreciate it 17:11 since we're overtime, I'll stop here formally and end the meeting.. 17:11 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)