== Meeting information == * #ubuntu-meeting: Developer Membership Board Meeting - 2025-09-15, started by athos, 15 Sep at 17:16 — 17:23 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-09-15-17.16.log.html == Meeting summary == === Attendees === Discussion started by athos at 17:16. === Ubuntu PPU Applications === Discussion started by athos at 17:16. * '''Ubuntu Server packageset PPU Application for Renan Rodrigo''' (athos, 17:17) * ''LINK:'' https://wiki.ubuntu.com/RenanRodrigo/UbuntuServerDeveloperApplication (athos, 17:17) * '''Set of questions the DMB asked Renan and a (mostly raw) transcription of his answers.''' (athos, 17:17) * Robie acknowledges that Renan's application is very good and detailed. (athos, 17:21) * ''VOTE:'' Renan Rodrigo Ubuntu Server packageset PPU vote results summary (Carried) (athos, 17:21) * athos abstained because he has been mentoring Renan through his packaging journey in the past few months (athos, 17:21) * ''ACTION:'' Utkarsh will handle the paperwork / announcement on Renan's Server team PPU application approval (athos, 17:22) === Meeting Summary === Discussion started by athos at 17:22. * Renan Rodrigo Barbosa applied for server package set upload rights. His application was approved. (athos, 17:22) * ''ACTION:'' cpaelzer will engage with the DKMS applicant and their endorsers to explain the feedback and the need for endorsements from recent sponsors. (athos, 17:22) * ''ACTION:'' utkarsh and athos will clean up the obsolete packagesets together, as requested in the mailing list (athos, 17:22) * ''ACTION:'' rbasak will continue the discussion on the need of a separate packageset for kernel related packages in Matrix. (athos, 17:22) == Vote results == * [[https://ubottu.com/meetingology/logs/ubuntu-meeting/2025/ubuntu-meeting.2025-09-15-17.16.log.html#76|Renan Rodrigo Ubuntu Server packageset PPU vote results summary]] * Motion carried (For: 1, Against: 0, Abstained: 0) * Voters: athos == Action items, by person == * athos * utkarsh and athos will clean up the obsolete packagesets together, as requested in the mailing list * cpaelzer * cpaelzer will engage with the DKMS applicant and their endorsers to explain the feedback and the need for endorsements from recent sponsors. * rbasak * rbasak will continue the discussion on the need of a separate packageset for kernel related packages in Matrix. * **UNASSIGNED** * Utkarsh will handle the paperwork / announcement on Renan's Server team PPU application approval == People present (lines said) == * athos (100) * meetingology (12) * rbasak (0) * juliank (0) * utkarsh2102 (0) * cpaelzer (0) * bdrung (0) * renanrodrigo (0) == Full log == 17:16 #startmeeting Developer Membership Board Meeting - 2025-09-15 17:16 Meeting started at 17:16:02 UTC. The chair is athos. Information about MeetBot at https://wiki.ubuntu.com/meetingology 17:16 Available commands: action, commands, idea, info, link, nick 17:16 Today's meeting was held through a video call. We are starting this meeting here to make sure the minutes are logged in a centralized place. 17:16 #topic Attendees 17:16 #nick rbasak 17:16 #nick juliank 17:16 #nick utkarsh2102 17:16 #nick cpaelzer 17:16 #nick bdrung 17:16 #nick renanrodrigo 17:16 #topic Ubuntu PPU Applications 17:17 #subtopic Ubuntu Server packageset PPU Application for Renan Rodrigo 17:17 #link https://wiki.ubuntu.com/RenanRodrigo/UbuntuServerDeveloperApplication 17:17 #subtopic Set of questions the DMB asked Renan and a (mostly raw) transcription of his answers. 17:17 rbasak asked "let's say the current version in the development release is 1.1.0-1 and you're considering updating it to 1.1.1-1. So the third digit is going up. What are the things that you might need to check in relation to the date of the time that you're being asked to make that upload?" 17:17 rbasak: "if you look at the calendar and consider the date that you are being asked to make that change, what would be relevant to check" 17:17 renanrodrigo: "Okay. I would say that this should be like a minor like as I said a macro release based on the version but not all upstreams follow semantic versioning. So the first thing I would check is like what are the changes upstream. Then based on the calendar the first thing that comes to mind is that I would need to check like the development milestones to see if we have some kind of freeze 17:17 like feature freeze or beta freeze or user interface freeze and then check how those changes apply to the eventual freeze that we have. If there is no freeze code review and and things should be enough" 17:17 rbasak: "When you're checking the upstream changes, what are the sorts of things, let's say it's feature freeze, what are the sorts of things that are relevant that you're looking for that would make it invalid under feature freeze to upload that package versus what would be acceptable?" 17:17 renanrodrigo: Well, I'm assuming it's an upstream that we trust. So, we can like see the release notes, we can see the change logs and check like which things are just bug fixes and which things smell like changing behavior. So I would check the changes and see the documentation about what is exactly changing to to see if it fits or not and I would consider that the change of behavior that is 17:17 acceptable immediately is not working to working otherwise if it's already working but starts working in a different way I would ask for permission using a exception request. 17:17 rbasak: And what if the upstream, or maybe it's someone in canonical, asking you to make the change because they've got something to deliver. What if they start insisting to you that there's no change to existing behavior. It's just new behavior that they're adding. Does that qualify? 17:18 renanrodrigo: All right. Yeah, that qualifies for the same scrutiny. It is not because it's internal from canonical that I should not do it. 17:18 renanrodrigo: Uh then the extra steps are again this is is it an upstream that we trust or the canonical person trusts it's it's fine to see the documentation if if if not checking the code may be actually better like for the specific fixes that have been uploaded and then I understand there is canonical pressure but canonical pressure shouldn't be the immediate reason to upload a package you should 17:18 talk to people you should make sure that everyone pressuring has it exact has documented somehow in a bug or in an in an internal email if it's something internal. But it needs to be explicit that everyone understands the risks of just doing things because when the when the like the press studio on what's been done has been disclaimed 17:18 rbasak: Mhm. So, so let's say that you inspect it carefully and you are satisfied that they are correct when they tell you that it doesn't change any existing behavior. It's just adding new behavior but it is after feature freeze. 17:18 rbasak: What are your next steps? 17:18 renanrodrigo: So the next steps for the development release opening a feature freeze exception and then explaining the situation uh with the appropriate information of why it would be needed for the development release. If it's an SRU then it I need to check like specific package exceptions or or else also ping the SRU team and make them aware 17:18 rbasak: Okay. Um let's say that you so that's the end of that question but I can carry on with the same example. Um so let's say that uh a feature freeze exception is granted by the release team. Um so you are going to upload that package. uh you do upload that package uh with uh you will have your new DUT powers to be able to do that, right? Um and then um once that's done or what are your 17:18 responsibilities then? 17:18 rbasak: What are your responsibilities after you've done the dput successfully? 17:18 renanrodrigo: All right. So when I do the debug successfully, I'm actually uploading it to the proposed pocket. So I need to see if auto package tests are passing which I should have checked before at least for the package itself. 17:18 renanrodrigo: But Britney is going to kick off all the reverse dependency testing as well. And I need need to make sure that all of those testing are passing tests are passing and I didn't break anything with that upload. Um to do like some kind of like um like verification on the excuses page to make sure that it actually migrates to the release bucket 17:18 rbasak: Where would you look if there's a problem and it's not migrating? 17:18 renanrodrigo: Well, at first the excuses page the upgrade update excuses there's one for a release and the default one is the development release. Uh if it says in the excuse page then it's ready like that it will attempt migration but it never migrates. It seems like there may be different conflicts that are not listed there. So there is the raw output of the of excuses that can be found. So I can 17:18 look at the raw output and see what's happening there. I actually had to do that for a couple of uploads that were sponsored for me this cycle. 17:18 rbasak: How did you fix it? 17:19 renanrodrigo: Well, one of them I didn't fix it because it was the Ruby stack stuff like um I had problems with PCS migrating because it needed to migrate together with the plethora of packages all the Ruby related dependencies and Ruby on Rails like Rails was one of the culprits and then it was like fixed by someone else. So I was just watching it. Uh but I was helping try I was trying to help 17:19 debug why the the the Ruby stack would uninstall Pacemaker when Pacemaker was not related directly to those packages at all. It was like indirect dependencies. So I helped troubleshooting that and I posted that on Matrix. So Simon Chopa and uh Utkash were seeing the messages. So it was about communication not technical stuff. 17:19 utkarsh: let's say you have a package version 1.2.3-4 17:19 utkarsh: and you have that version since Noble, well, let's go with Jammy, in all the same pockets. 17:19 utkarsh: so jammy, noble, plucky, and questing. you wanted to do a bug fix and then SRU it, what are the versionings you would use? 17:19 renanrodrigo: right. So for the development release, it should be 1 2 3-4 Ubuntu one because I'm actually adding a patch on top of that package. But when SRU in that I need to be aware that people may be upgrading from Jimmy to noble and then onwards. So it uh the upgrade path cannot be broken by the version numbers. The Ubuntu maintainers handbook has the uh the recommended strings for that. So I 17:19 would probably use um the Ubuntu zero tilda and then the release number itself because then the tilda guarantees that the version is behind what we we have in the second part version is going to be like 22 24 and it will like enable you to upgrade the package. 17:19 cpaelzer: Robbie outlined the case that you will then have the ability to depot stuff which means you also become a sponsor a potential sponsor for packages. When somebody says hey there's adaptive or an MR what would you look into when sponsoring is it the code is obvious. Is there anything you would look into other than that? 17:19 renanrodrigo: Yes. So, uh there are three things that I think needs to be checked. 17:19 renanrodrigo: The first one as you said it's obvious is the code itself. The second thing is the like the Ubuntu specific things like for the dev packaging. I would take a look in the change log. 17:19 renanrodrigo: if something is relevant in the change log, it should be either in Debian news if it's or or Debian like uh read me. Um I would check the version number if that's correct. I would do some security check if the package builds check if the auto package tests are passing at least for the package itself. So all of the Ubuntu specific stuff and the next thing is intention like why exactly 17:19 this upload has been done like this should be explicit in the change log itself. If it's not, I would ask. And if it's a bug fix, as Utkash mentioned that can be affecting other releases, I can ask for the intention to SRO that or not and guide the people through the process. So I could sponsor the package and also the SRO if needed. So code Ubuntu specific things, the dev packaging things and um 17:19 intention. 17:19 bdrung: So imagine you stumble upon a bug in some package um and you decide okay uh time to fix that bug. What would be your steps? 17:20 renanrodrigo: So yeah, the first step if I if I already know the root like the root cause for the bug, I would just like add a patch. Uh if it's a bug in the Ubuntu packaging itself, I can do it directly. If it's a bug in the code, I would use like a patch file and then quilt to apply it. Um after I do the bug fix, I would then think about like the complexity of this bug fix. If it's something 17:20 obvious, like really obvious, I can just prepare the package and upload it myself. But if it involves any kind of complexity, maybe it's like that I maybe think it's it's needed for other like people to see, I would also request a review, open an MP so people can check if my bug fix makes sense. And I I had someone once talking to me about like how oneliners would be easier to upload than actually 17:20 like chunks of code. But there are some chunks of code that just make sense when you read it. 17:20 renanrodrigo: and they are oneliners like if it's a reject or something I will always ask for reviews and rejaxes and these kind of things you know so those are two examples of of how my my mindset for fixing bugs is and that's completely unrelated to Ubuntu packaging that's like for the day job like since years um any up to complex change needs to be reviewed before once approved then I can like 17:20 upload the package uh to proposed and then proceed with the proceed do the procedure that we discussed 17:20 cpaelzer: I I'm trying to allude to what Benjamin might have looked at asked for. Are there any other parties to involve? 17:20 renanrodrigo: So it depends if it's I would say the first thing that you need to check is if this bug also exists upstream. So that will be about making the fix. If I'm not writing the fix myself, I would look for the patch upstream. uh depending on the upstream version if it if that's not compatible also check Debian and see if Debian has already patched it because it's always preferred to bring 17:20 the patch from Debian so we reduce the burden of maintenance in the Ubuntu site and if not if it's not present in other things if if it's Ubuntu specific then it's everything I already said if it's not Ubuntu specific but is upstream or in Debian I would try to 17:20 renanrodrigo: bring it in and then spread it out to any parties that don't have the fix Yeah. So if I if I bake a fix in Ubuntu and that's has happened for instance um the libxml 2 migration the cycle it broke a couple no a few PHP packages and they didn't have fixes upstream because upstream is not building with the new libxml 2 yet uh not even Debian was there like the bugs were triggered because 17:20 it was an experimental so I patched all the packages in Ubuntu I sent all the packages to Debian I sent all of the patches also upstream Uh, one of them was actually accepted upstream and the others are in debant now. So I I forwarded 17:20 bdrung: Yeah, that's what I also wanted to know. What is your upstream migration? Um, and also submitting the patch upstream is one way to get it reviewed. Thanks. Next question, Robbie 17:20 rbasak: So let's say that uh you're going to do an upload or you're considering doing an upload for something that is contentious in some way. 17:20 rbasak: Uh you are aware that there's some Ubuntu developer who's going to be unhappy by uh as a result of this upload. Uh so before you do the upload, what are your steps? 17:20 renanrodrigo: I live by the heat and space bar theory. Everyone will be happy about things at the time, you know, like. So I think those things those things should be um I would invoke the code of conduct here like we are a community everyone should have voice and everyone should be heard. If I do need to do this upload if I'm interested in doing this upload for anyway the first thing is discussing 17:21 with the people that would be unhappy and trying to find common grounds. Um I think arguments are and discussions are necessary. So we have the public channels for that. We have the bugs themselves. We have MPs and every like we we do have like public sources of documentation for that. I'm sure that matrix is not ideal yet because like logs and links from matrix are hell but still people are on 17:21 matrix. 17:21 renanrodrigo: I can just like post it there and say hey I'm about to upload this. I know like there is this and this and this. How can we sort sort that out? Like what are the rest like where are what are your concerns? What are the restrictions that we have here and how can we solve them? I think 90% of the problems are solvable when you communicate to people and the other 10% man this experience 17:21 is from Ubuntu pro the other 10 10% like someone else is going to decide for me but that my part is to explain what's happening and and try to bring the parties together so we find a solution if I have an impass I have as I said people to decide for me if it's canonical specific probably mark 17:21 rbasak: What if you have an impass? 17:21 renanrodrigo: Shuttleworth is going to define what's going to happen or not in the Ubuntu world I see that it happens way less often than in pro because like pro was as I said completely different so but in the Ubuntu world they're also decision makers uh if it's a change that is making like big changes in the archive and there's the archive team for stuff there's the council right that I can always 17:21 bring stuff if it's like 17:21 renanrodrigo: community related like is if it's an impass that is nontechnical There is the technical board if the impass is actually technical. So there are people designed to solve impasses in any kind of of situation. 17:21 #info Robie acknowledges that Renan's application is very good and detailed. 17:21 #vote Renan Rodrigo Ubuntu Server packageset PPU vote results summary 17:21 Please vote on: Renan Rodrigo Ubuntu Server packageset PPU vote results summary 17:21 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:21 +1 17:21 +1 received from athos 17:21 #endvote 17:21 Voting ended on: Renan Rodrigo Ubuntu Server packageset PPU vote results summary 17:21 Votes for: 1, Votes against: 0, Abstentions: 0 17:21 Motion carried 17:21 utkarsh2102 +1 17:21 rbasak +1 17:21 #info athos abstained because he has been mentoring Renan through his packaging journey in the past few months 17:21 juliank +1 17:21 cpaelzer +1 17:22 lvoytek +1 (proxied throught cpaelzer) 17:22 bdrung +1 17:22 Congratulations, renanrodrigo 17:22 #action Utkarsh will handle the paperwork / announcement on Renan's Server team PPU application approval 17:22 * meetingology Utkarsh will handle the paperwork / announcement on Renan's Server team PPU application approval 17:22 #topic Meeting Summary 17:22 #info Renan Rodrigo Barbosa applied for server package set upload rights. His application was approved. 17:22 The meeting moved on to discussions about mailing list items, including a DKMS upload rights application and the cleanup of obsolete packagesets. 17:22 First, we discussed the kernel team's applications for DKMS package set rights. There is a concern that previous kernel team applicants were unsuccessful not due to their own failings, but due to insufficient mentoring from their sponsors. Examples of quality issues in kernel-related uploads were mentioned, such as incorrect DEP3 headers and user space packages not adhering to policy 17:22 Some concerns about the scope of the kernel package set were raised, noting that it includes packages like DKMS, firmware, and Ubuntu drivers common, which may not strictly meet the "Linux kernel" description. rbasak suggested that the package set had experienced "accidental scope creep" and should be reduced to only kernel packages, but also acknowledged the need for a "kernel related package set" 17:22 for non-kernel items to provide a clearer path for applicants 17:22 Concerns about the quality of the DKMS applicant's endorsement were raised, suggesting that the DMB should set clear expectations for the kernel team. 17:22 Notes that the same endorser previously sponsoring uploads that were deemed below quality were made. 17:22 #action cpaelzer will engage with the DKMS applicant and their endorsers to explain the feedback and the need for endorsements from recent sponsors. 17:22 * meetingology cpaelzer will engage with the DKMS applicant and their endorsers to explain the feedback and the need for endorsements from recent sponsors. 17:22 rbasak highlighted the importance of SRUs for DKMS maintenance and expressed a desire to see more recent ones in that application. 17:22 bdrung pointed out that the `deb` file for the RTL8812AU package present in the application has an origin line in its patch header that only links to the git repository and not the specific commit. rbasak acknowledged this as a substandard detail that was "not quite right". 17:22 Benjamin Drung agreed with Robie Basak that there should be a separate PPU for kernel-related packages, stating that only the kernel should be included in the kernel package set. 17:22 #action utkarsh and athos will clean up the obsolete packagesets together, as requested in the mailing list 17:22 * meetingology utkarsh and athos will clean up the obsolete packagesets together, as requested in the mailing list 17:22 #action rbasak will continue the discussion on the need of a separate packageset for kernel related packages in Matrix. 17:22 * meetingology rbasak will continue the discussion on the need of a separate packageset for kernel related packages in Matrix. 17:23 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)