== Meeting information == * #ubuntu-meeting: Developer Membership Board meeting, started by rbasak, 18 Mar at 19:02 — 20:00 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-03-18-19.02.log.html == Meeting summary == === Package Set/Per Package Uploader Applications === Discussion started by rbasak at 19:02. * '''Miriam España Acebal''' (rbasak, 19:02) * ''LINK:'' https://wiki.ubuntu.com/MiriamEspanaAcebal/ServerUploaderDeveloperApplication (rbasak, 19:02) * ''LINK:'' https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html (mirespace, 19:24) * ''LINK:'' https://ubuntu-archive-team.ubuntu.com/proposed-migration/jammy/update_excuses.html (mirespace, 19:25) * ''VOTE:'' Grant mirespace upload access to the ubuntu-server packageset (Carried) (rbasak, 19:45) * ''ACTION:'' rbasak to announce mirespace's successful application (rbasak, 19:45) * ''ACTION:'' rbasak to adjust ACLs for mirespace's successful application (rbasak, 19:45) === Review of previous action items === Discussion started by rbasak at 19:46. * ''ACTION:'' Utkarsh to review the tasks for a DMB election and decide if he can take that on. If not we should choose somebody to run the election. (rbasak, 19:47) * ''ACTION:'' teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) (rbasak, 19:47) === Outstanding mailing list requests to assign === Discussion started by rbasak at 19:47. === Open TB bugs === Discussion started by rbasak at 19:50. * No open TB bugs (rbasak, 19:51) === AOB === Discussion started by rbasak at 19:51. == Vote results == * [[https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-03-18-19.02.log.html#93|Grant mirespace upload access to the ubuntu-server packageset]] * Motion carried (For: 4, Against: 0, Abstained: 0) * Voters: rbasak, sil2100, seb128, bdmurray == Action items, by person == * mirespace * rbasak to announce mirespace's successful application * rbasak to adjust ACLs for mirespace's successful application * rbasak * rbasak to announce mirespace's successful application * rbasak to adjust ACLs for mirespace's successful application * **UNASSIGNED** * Utkarsh to review the tasks for a DMB election and decide if he can take that on. If not we should choose somebody to run the election. * teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) == People present (lines said) == * mirespace (58) * rbasak (49) * seb128 (25) * sil2100 (17) * meetingology (15) * bdmurray (3) == Full log == 19:02 #startmeeting Developer Membership Board 19:02 Meeting started at 19:02:19 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology 19:02 Available commands: action, commands, idea, info, link, nick 19:02 #topic Package Set/Per Package Uploader Applications 19:02 #subtopic Miriam España Acebal 19:02 mirespace: welcome! 19:02 rbasak: thank you! 19:02 #link https://wiki.ubuntu.com/MiriamEspanaAcebal/ServerUploaderDeveloperApplication 19:03 mirespace: would you like to introduce yourself please? 19:03 Hi, my name is Miriam España Acebal (yes, two surnames… Spain is different) and I work as a distro engineer in the CPC team at Canonical. 19:03 When I joined Canonical in 2021 I started in the Server Team and I’m still quite involved with them yet. 19:04 Besides this, I may be mostly known for packaging dotnet (dotnet6 and dotnet7) and introduce it as New in 2022 on Kinetic. 19:04 I’m based in Granada (Spain). 19:04 Thank you! I can start with some questions. 19:05 ok 19:05 Where can you find details of the various freeze dates applicable to the current Ubuntu development release cycle? And what freeze applies to the archive at the moment? 19:05 In the Noble Schedule: https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649 19:06 We are in Feature Freeze 19:06 (/me will have a question when rbasak is done with his) 19:06 and also, you can find that info on IRC, the topic of #ubuntu-devel and #ubuntu-release on Libera Chat is generally updated to indicate the current freeze status. 19:07 sil2100: ack 19:08 mirespace: if a package is on version 1.2-3ubuntu1 and you're considering uploading 1.2.1-0ubuntu1, then what information do you need to decide if the upload would be acceptable during feature freeze? 19:09 the -0 before the ubuntu is telling that we are uploading a version from upstream that us not in Debian, and it would be acceptable if the diff between that versions includes fixes 19:10 Is there anything that might be present in the diff that would make the upload unacceptable? 19:11 cosmetic changes that makes the review more difficult and new features described in the changelog or CHANGES file 19:11 What if the diff contains new features that aren't described in the changelog or CHANGES file? 19:12 do you mean new features per se, not fixing/ or correcting a anormal behaviour? 19:13 Yes - so for example imagine that on examining the diff, you notice something that is without doubt a new feature. 19:14 So, we are talking about a MicroRelease upgrade, and we would need a microrelease exception in place (approved by the release team) to allow it 19:14 MRE 19:15 in thios case, the .1 before the -0 points to a microrelease upgrade 19:15 s/thios/thios/ 19:15 aaah... *this 19:16 OK thanks. Let's move on. I have more questions, but shall we take turns? sil2100 do you want to go next? 19:16 o/ 19:16 o? 19:16 I have 2 small questions 19:16 o/ 19:16 ok 19:17 ups (MRE approved by SRU team, sorry) 19:17 1) When preparing an SRU, we require filling out the 'template' information in the bug. Part of the template is the Regression Potential / Where problems could occur section. Can you tell me what it is for? 19:18 What is the purpose of that section? 19:18 With that part, the uploader demonstrates that the risk of the upload had been deeply considered 19:19 o/ (queuing for a question after Lukasz) 19:19 Thinking about what else could occurs if my package lands in the archive... not only dfailures of the package itlself 19:19 also, how it could affect othe packages that usally interacts with it 19:20 or user/third party scripts that use any part of the package uploaded 19:20 Okay, second question: 19:21 2) When you prepare and upload your SRU, and it gets accepted by the SRU team into -proposed, what are your next responsibilities regarding the SRU? What is expected of you? 19:22 me (or anyone else) should test the package in -proposed to verify the bug is fixed 19:22 with the test plan provided by me in the sru template 19:22 that is used to fill the bug 19:22 if the package, later, it's released because the aging period is reached 19:23 I should take a look to the component mistmached page to see if the package builds OK or have a regression (itself or with other packages) 19:24 I mean, taking care it passes the tests (DEP8) for the archs it builds 19:24 the comp0onent mismatche no, the update excuses, sorry 19:24 You mentioned component mismatches? 19:24 Ah, yes 19:24 This is what I wanted to see! 19:24 https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html 19:24 (too much MIR work lately, sorry) 19:25 :) 19:25 mirespace: this is the update_excuses page for the development series. If, say, you had an upload in jammy, where would you look for autopkgtest results? 19:25 https://ubuntu-archive-team.ubuntu.com/proposed-migration/jammy/update_excuses.html 19:26 the scheme would be : https://ubuntu-archive-team.ubuntu.com/proposed-migration//update_excuses.html 19:26 Ok, thanks! That's enough from me 19:26 seb128, rbasak: ^ 19:27 seb128: over to you 19:27 mirespace, you mentioned a MRE earlier ... what is a MRE for you and where/to which serie does that apply? 19:28 we want to provide to users of our supported series (LTS or interim at the moment of the MRE) with the more stable experience when using a piece of software 19:29 to provide this, sometimes is needed to upgrade versions of packages in stable releases that include not only security fixes : new features too, in the sense 19:30 of replacing supporting of a feature/protocol/package that is going to dissapear 19:30 or to maintain the package usable in a supported series 19:31 It's used mostly for packages that impact the series/are very used in the community 19:31 i.e., dpdk 19:31 mirespace, so for a such case what would be the process? would you need to ask for the exception (and if so how/to who)? or is there any guideline describing those exception cases? 19:32 You need to follow https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases 19:33 Writting the MRE exception to be included into the https://wiki.ubuntu.com/StableReleaseUpdates, once approved by the SRU team 19:33 mirespace, ok, thanks for your replies, that's enough for me :) 19:34 in that exception you need to expose the reasons about why we should do it, what extra test we are doing 19:34 and special considerations to take care (release cadence, for example) 19:34 ok ... sorry for continuing answering :$ 19:34 no worry, please keep writting if you have more to say 19:35 it's ok :) 19:35 it's sometime difficult in written to know when the other side is done write 19:35 just finish with some sort of :) 19:35 I agree totally wit you on that 19:35 good idea 19:36 OK I guess that line of questions is done? I was going to ask about proposed migration in the development release, but you've already basically answered my question above. 19:36 So I have no further questions. 19:36 Anyone else? 19:36 no further question from me 19:38 #vote Grant mirespace upload access to the ubuntu-server packageset 19:38 Please vote on: Grant mirespace upload access to the ubuntu-server packageset 19:38 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') 19:38 +1 19:38 +1 received from rbasak 19:38 +1 19:38 +1 received from sil2100 19:39 +1 (though I think there is some confusions about MRE and rules applying to SRU of micro-releases, that's not a blocker for a set application but should be resolved on the way to coredev) 19:39 +1 (though I think there is some confusions about MRE and rules applying to SRU of micro-releases, that's not a blocker for a set application but should be resolved on the way to coredev) received from seb128 19:39 I'll work on that seb128: 19:40 +1 19:40 +1 received from bdmurray 19:40 kanashiro: vote? 19:40 * bdmurray needs to run though 19:42 mirespace, the policy section you referred to is about microreleases including bugfixing, it doesn't cover features. Also usually a MRE is a special rule you ask for a special projects (like you mentioned for services); it wouldn't be the solution to a new feature being added to a microrelease of a random package 19:43 mirespace, also I got slightly confused that the MRE mention came in a discussion about feature freeze, which means devel release and not a stable one, so the process would be a FFe 19:44 yes, you're right... i had in my notes new upstream (microrelease) 19:44 for FFe 19:45 #endvote 19:45 Voting ended on: Grant mirespace upload access to the ubuntu-server packageset 19:45 Votes for: 4, Votes against: 0, Abstentions: 0 19:45 Motion carried 19:45 I have got a prepared answer about FFe 19:45 Congratulations mirespace! 19:45 mirespace, congratulations! 19:45 #action rbasak to announce mirespace's successful application 19:45 * meetingology rbasak to announce mirespace's successful application 19:45 thank you! _sweating_ 19:45 #action rbasak to adjust ACLs for mirespace's successful application 19:45 * meetingology rbasak to adjust ACLs for mirespace's successful application 19:46 Congrats! 19:46 #topic Review of previous action items 19:46 MRE page caught : https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases aaah 19:47 The two people with actions aren't here, so I'll carry them both over. 19:47 #action Utkarsh to review the tasks for a DMB election and decide if he can take that on. If not we should choose somebody to run the election. 19:47 * meetingology Utkarsh to review the tasks for a DMB election and decide if he can take that on. If not we should choose somebody to run the election. 19:47 than kyou sil2100 ! 19:47 #action teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) 19:47 * meetingology teward follow up to get all application process wiki/docs to explain the process to be able to edit wiki pages, for applicants who don't yet have wiki edit access (carried over) 19:47 #topic Outstanding mailing list requests to assign 19:48 there is a kubuntu set update request that teward might be handling or not? (I'm unsure from his message) 19:48 I remember seeing his reply, but I don't see it in my list archives 19:48 Any idea where it is? 19:48 In two weeks people will have expired from the team 19:49 rbasak, it's on the dev-membership one 19:49 bdmurray, yes, I was going to mention that once we are in AOB :) 19:49 seb128: thanks. It should be on the public list really :-/ 19:50 seb128: given you replied today, shall we treat it as making progress, and follow up next time? 19:50 +1 19:50 I don't see anything else unaddressed on the ML. 19:50 #topic Open TB bugs 19:51 #info No open TB bugs 19:51 #topic AOB 19:51 what bdmurray said ^ 19:51 Thank you for noting the schedule. 19:51 kanashiro, bdmurray and me will have our membership expired by the next meeting 19:52 I guess in Utkarsh's absence perhaps we should assume that the answer is that no, he doesn't have the capacity, and so we should find someone else to run it? 19:52 ...and the other seats expire on 16 June 19:53 I think it would be nice but any idea who the someone could be? 19:53 I have done it in the past and am happy to volunteer to do it again 19:53 also I don't remember how we ended up there but it's unfortunate those expirations are back to back 19:53 I would like to combine the two sets though, rather than run two elections two months apart. 19:53 +1 from me 19:54 to be clear +1 for you to handle it but also for combining 19:54 Since the results are ranked, we can agree that the top three ranking candidates will take their seats immediately, and the other four will take their seats in June. 19:54 Same here 19:54 * sil2100 needs to drop, sadly o/ 19:55 unfortunate hose expirations are back to back> should we try to re-stagger them? 19:55 unsure how we do that, it's also late in the slot to have that discussion now? 19:56 For example, normally the term is two years. We could make the second set one year only, so then we'll have two halves (modulo integer division) staggered one year apart again. 19:56 I would say just go with the election and the new board can put that on their agenda 19:59 Let me write to the list with a detailed proposal, since there are some other bits I can think of that I need agreement for in order that the combined election will work. 19:59 Anything else to discuss? 20:00 not from me 20:00 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)