19:02 <rbasak> #startmeeting Developer Membership Board
19:02 <meetingology> Meeting started at 19:02:19 UTC.  The chair is rbasak.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:02 <meetingology> Available commands: action, commands, idea, info, link, nick
19:02 <rbasak> #topic Package Set/Per Package Uploader Applications
19:02 <rbasak> #subtopic Miriam España Acebal
19:02 <rbasak> mirespace: welcome!
19:02 <mirespace> rbasak: thank you!
19:02 <rbasak> #link https://wiki.ubuntu.com/MiriamEspanaAcebal/ServerUploaderDeveloperApplication
19:03 <rbasak> mirespace: would you like to introduce yourself please?
19:03 <mirespace> 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 <mirespace> When I joined Canonical in 2021 I started in the Server Team and I’m still quite involved with them yet.
19:04 <mirespace> Besides this, I may be mostly known for packaging dotnet (dotnet6 and dotnet7) and introduce it as New in 2022 on Kinetic.
19:04 <mirespace> I’m based in Granada (Spain).
19:04 <rbasak> Thank you! I can start with some questions.
19:05 <mirespace> ok
19:05 <rbasak> 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 <mirespace> In the  Noble Schedule: https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649
19:06 <mirespace> We are in Feature Freeze
19:06 <sil2100> (/me will have a question when rbasak is done with his)
19:06 <mirespace> 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 <rbasak> sil2100: ack
19:08 <rbasak> 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 <mirespace> 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 <rbasak> Is there anything that might be present in the diff that would make the upload unacceptable?
19:11 <mirespace> cosmetic changes that makes the review more difficult and new features described in the changelog or CHANGES file
19:11 <rbasak> What if the diff contains new features that aren't described in the changelog or CHANGES file?
19:12 <mirespace> do you mean new features per se, not fixing/ or correcting a anormal behaviour?
19:13 <rbasak> Yes - so for example imagine that on examining the diff, you notice something that is without doubt a new feature.
19:14 <mirespace> 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 <mirespace> MRE
19:15 <mirespace> in thios case, the .1 before the -0 points to a microrelease upgrade
19:15 <mirespace> s/thios/thios/
19:15 <mirespace> aaah... *this
19:16 <rbasak> OK thanks. Let's move on. I have more questions, but shall we take turns? sil2100 do you want to go next?
19:16 <sil2100> o/
19:16 <mirespace> o?
19:16 <sil2100> I have 2 small questions
19:16 <mirespace> o/
19:16 <mirespace> ok
19:17 <mirespace> ups (MRE approved by SRU team, sorry)
19:17 <sil2100> 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 <sil2100> What is the purpose of that section?
19:18 <mirespace> With that part, the uploader demonstrates that the risk of the upload had been deeply considered
19:19 <seb128> o/ (queuing for a question after Lukasz)
19:19 <mirespace> Thinking about what else could occurs if my package lands in the archive... not only dfailures of the package itlself
19:19 <mirespace> also, how it could affect othe packages that usally interacts with it
19:20 <mirespace> or user/third party scripts that use any part of the package uploaded
19:20 <sil2100> Okay, second question:
19:21 <sil2100> 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 <mirespace> me (or anyone else) should test the package in -proposed to verify the bug is fixed
19:22 <mirespace> with the test plan provided by me in the sru template
19:22 <mirespace> that is used to fill the bug
19:22 <mirespace> if the package, later, it's released because the aging period is reached
19:23 <mirespace> 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 <mirespace> I mean, taking care it passes the tests (DEP8) for the archs it builds
19:24 <mirespace> the comp0onent mismatche no, the update excuses, sorry
19:24 <sil2100> You mentioned component mismatches?
19:24 <sil2100> Ah, yes
19:24 <sil2100> This is what I wanted to see!
19:24 <mirespace> https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html
19:24 <mirespace> (too much MIR work lately, sorry)
19:25 <mirespace> :)
19:25 <sil2100> 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 <mirespace> https://ubuntu-archive-team.ubuntu.com/proposed-migration/jammy/update_excuses.html
19:26 <mirespace> the scheme would be :  https://ubuntu-archive-team.ubuntu.com/proposed-migration/<supported_series>/update_excuses.html
19:26 <sil2100> Ok, thanks! That's enough from me
19:26 <sil2100> seb128, rbasak: ^
19:27 <rbasak> seb128: over to you
19:27 <seb128> mirespace, you mentioned a MRE earlier ... what is a MRE for you and where/to which serie does that apply?
19:28 <mirespace> 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 <mirespace> 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 <mirespace> of replacing supporting of a feature/protocol/package  that is going to dissapear
19:30 <mirespace> or to maintain the package usable in a supported series
19:31 <mirespace> It's used mostly for packages that impact the series/are very used in the community
19:31 <mirespace> i.e., dpdk
19:31 <seb128> 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 <mirespace> You need to follow https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
19:33 <mirespace> Writting the MRE exception to be included into the https://wiki.ubuntu.com/StableReleaseUpdates, once approved by the SRU team
19:33 <seb128> mirespace, ok, thanks for your replies, that's enough for me :)
19:34 <mirespace> in that exception you need to expose the reasons about why we should do it, what extra test we are doing
19:34 <mirespace> and special considerations to take care (release cadence, for example)
19:34 <mirespace> ok ... sorry for continuing answering :$
19:34 <seb128> no worry, please keep writting if you have more to say
19:35 <mirespace> it's ok :)
19:35 <seb128> it's sometime difficult in written to know when the other side is done write
19:35 <seb128> just finish with some sort of </end> :)
19:35 <mirespace> I agree totally wit you on that
19:35 <mirespace> good idea
19:36 <rbasak> 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 <rbasak> So I have no further questions.
19:36 <rbasak> Anyone else?
19:36 <seb128> no further question from me
19:38 <rbasak> #vote Grant mirespace upload access to the ubuntu-server packageset
19:38 <meetingology> Please vote on: Grant mirespace upload access to the ubuntu-server packageset
19:38 <meetingology> 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 <rbasak> +1
19:38 <meetingology> +1 received from rbasak
19:38 <sil2100> +1
19:38 <meetingology> +1 received from sil2100
19:39 <seb128> +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 <meetingology> +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 <mirespace> I'll work on that seb128:
19:40 <bdmurray> +1
19:40 <meetingology> +1 received from bdmurray
19:40 <rbasak> kanashiro: vote?
19:40 * bdmurray needs to run though
19:42 <seb128> 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 <seb128> 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 <mirespace> yes, you're right... i had in my notes new upstream (microrelease)
19:44 <mirespace> for FFe
19:45 <rbasak> #endvote
19:45 <meetingology> Voting ended on: Grant mirespace upload access to the ubuntu-server packageset
19:45 <meetingology> Votes for: 4, Votes against: 0, Abstentions: 0
19:45 <meetingology> Motion carried
19:45 <mirespace> I have got a prepared answer about FFe
19:45 <rbasak> Congratulations mirespace!
19:45 <seb128> mirespace, congratulations!
19:45 <rbasak> #action rbasak to announce mirespace's successful application
19:45 * meetingology rbasak to announce mirespace's successful application
19:45 <mirespace> thank you! _sweating_
19:45 <rbasak> #action rbasak to adjust ACLs for mirespace's successful application
19:45 * meetingology rbasak to adjust ACLs for mirespace's successful application
19:46 <sil2100> Congrats!
19:46 <rbasak> #topic Review of previous action items
19:46 <mirespace> MRE page caught : https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases aaah
19:47 <rbasak> The two people with actions aren't here, so I'll carry them both over.
19:47 <rbasak> #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 <mirespace> than kyou sil2100 !
19:47 <rbasak> #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 <rbasak> #topic Outstanding mailing list requests to assign
19:48 <seb128> there is a kubuntu set update request that teward might be handling or not? (I'm unsure from his message)
19:48 <rbasak> I remember seeing his reply, but I don't see it in my list archives
19:48 <rbasak> Any idea where it is?
19:48 <bdmurray> In two weeks people will have expired from the team
19:49 <seb128> rbasak, it's on the dev-membership one
19:49 <seb128> bdmurray, yes, I was going to mention that once we are in AOB :)
19:49 <rbasak> seb128: thanks. It should be on the public list really :-/
19:50 <rbasak> seb128: given you replied today, shall we treat it as making progress, and follow up next time?
19:50 <seb128> +1
19:50 <rbasak> I don't see anything else unaddressed on the ML.
19:50 <rbasak> #topic Open TB bugs
19:51 <rbasak> #info No open TB bugs
19:51 <rbasak> #topic AOB
19:51 <seb128> what bdmurray said ^
19:51 <rbasak> Thank you for noting the schedule.
19:51 <seb128> kanashiro, bdmurray and me will have our membership expired by the next meeting
19:52 <rbasak> 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 <rbasak> ...and the other seats expire on 16 June
19:53 <seb128> I think it would be nice but any idea who the someone could be?
19:53 <rbasak> I have done it in the past and am happy to volunteer to do it again
19:53 <seb128> also I don't remember how we ended up there but it's unfortunate those expirations are back to back
19:53 <rbasak> I would like to combine the two sets though, rather than run two elections two months apart.
19:53 <seb128> +1 from me
19:54 <seb128> to be clear +1 for you to handle it but also for combining
19:54 <rbasak> 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 <sil2100> Same here
19:54 * sil2100 needs to drop, sadly o/
19:55 <rbasak> unfortunate hose expirations are back to back> should we try to re-stagger them?
19:55 <seb128> unsure how we do that, it's also late in the slot to have that discussion now?
19:56 <rbasak> 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 <seb128> I would say just go with the election and the new board can put that on their agenda
19:59 <rbasak> 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 <rbasak> Anything else to discuss?
20:00 <seb128> not from me
20:00 <rbasak> #endmeeting