=== JanC is now known as Guest7855 === JanC_ is now known as JanC === JanC_ is now known as JanC [18:53] hey there. I plan to be there to the DMB meeting but I will probably be ~10 min late, sorry [19:00] o/ [19:00] o/ [19:00] o/ [19:00] o/ [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] ACTION: 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] ACTION: 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] 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] 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] 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] #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 [20:00] Meeting ended at 20:00:06 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-03-18-19.02.moin.txt [20:00] Thanks all! [20:00] than you all seb128 rbasak bdmurray sil2100 ! [20:00] thanks rbasak [20:00] How bad are the nervesssssss [20:02] and thanks DMB members it was fun being part of the board (unsure if I'm going to re-apply yet, I'm struggling to find the needed time often) [20:03] rbasak, I guess next meeting is only with 4 members but it's still enough to get a quorum on votes if needed [20:03] rbasak, unless we have a list vote on your proposal before us 3 expire [20:19] seb128: a list vote is fine, but also when this has happened in the past the TB has always been willing to temporarily extend the existing terms to cover the gap. [20:19] I've emailed the list with my proposal. [20:19] thanks [20:19] I hope it is unambiguous and covers the edge cases. Please scrutinize! [21:32] i apologize i was not present rbasak and all. unexpected call into the office today for the whole day