16:09 <bdmurray> #startmeeting Developer Membership Board
16:09 <meetingology> Meeting started at 16:09:39 UTC.  The chair is bdmurray.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
16:09 <meetingology> Available commands: action, commands, idea, info, link, nick
16:09 <bdmurray> We'll start with applications
16:10 <bdmurray> #topic Ubuntu Core Developer Applications
16:10 <bdmurray> I believe fheimes application is still outstanding and he applied first
16:11 <rbasak> I don't think he's picked a meeting date to resume his application though?
16:11 <rbasak> IIRC he said he would be out of office at the time. I don't know how long that was for.
16:12 <sil2100> Yeah. SHould we maybe reach out to him with a reminder about that?
16:12 <bdmurray> #action bdmurray to check in with fheimes
16:12 * meetingology bdmurray to check in with fheimes
16:13 <bdmurray> #subtopic Ubuntu Core Developer Application - Dan Bungert
16:13 <bdmurray> dbungert: Could you introduce yourself?
16:13 <dbungert> https://wiki.ubuntu.com/dbungert/CoreDev
16:13 <dbungert> Hi - I am Dan Bungert
16:14 <rbasak> Hello!
16:14 <dbungert> I joined Canonical January of 2021, and have largely been focused on Subiquity and related matters since that time
16:14 <dbungert> I also assist on various Foundations related tasks, as needed to help the release keep moving
16:15 <bdmurray> https://wiki.ubuntu.com/dbungert/CoreDev
16:15 <rbasak> Thank you for doing +1 maintenance - I see a lot of sponsored uploads that look like they were related to that.
16:15 <rbasak> Sometimes this involves introducing a delta into a package in Ubuntu. Can you tell me about the processes involved in making sure that the packages remain maintained after this happens, please?
16:15 <dbungert> Merge-o-matic can help with that
16:16 <dbungert> it lists a "touched it last", it's good to check in with that value and keep the merge up to date or drop the merge if changes have been incorporated upstream or in Debian
16:17 <rbasak> Do you know of any packages that you "TIL" that need attention?
16:18 <dbungert> looks like I have 2 right now in Universe
16:18 <dbungert> hydra and oz
16:18 <dbungert> I will address them
16:19 <sil2100> dbungert: once you're done with rbasak's question, as you mentioned doing only 'a SRU': What are the additional things one has to consider when preparing and SRU for a stable series? What are some of the few additional constraints SRUs have over regular uploads to devel?
16:19 <rbasak> OK, thanks. I asked because I struggled to find experience of packages merges in your sponsored upload history. I did find three in the end.
16:20 <dbungert> rbasak: if you're content with the above, shall I do sil2100's question?
16:20 <rbasak> Yes - please go ahead. I think I have a further separate question on merges but I can awk that afterwards.
16:21 <dbungert> I look at SRUs as a big part of the value of Ubuntu.  People see the stable releases, especially the LTS, as a big reason to run Ubuntu
16:22 <dbungert> for SRUs we first fix in the development release, then follow the process to list the pros and cons of why it is interesting to provide that fix for a stable release, along with a test plan
16:22 <dbungert> then with some testing, the SRU can proceed
16:22 <dbungert> The wiki has great details on all the above
16:23 <sil2100> Are there some general constraints on what can and cannot be SRUed?
16:24 <dbungert> It's generally not preferred to mass merge an entire upstream release for a SRU.  Targetted fixes are preferred instead.
16:24 <dbungert> In some cases there are documented exceptions for that - Curtin has such an exception IIRC
16:24 <sil2100> Okay, thank you
16:25 <bdmurray> rbasak: did you have another question?
16:26 <teward> o/  (sorry i'm late, neck deep in an Microsoft Active Directory rebuild for a client)
16:26 <rbasak> dbungert: the three merges you have had sponsored that I found look fairly simple. Have you done any complex ones? Let's say that you had to do a merge where multiple changes took place in overlapping lines, that conflict with the changes made in Debian. How would you approach doing this?
16:27 <dbungert> In such a merge there are 3 versions to think about - the base version we patched, the ubuntu version, and the new version in debian
16:27 <dbungert> I like to start by getting the debdiff from the base version we patched to the ubuntu version, to see the actual changes that we consider interesting
16:28 <dbungert> then review those changes - are some of them upstream things and maybe incoporated in the unpatched upstream version?
16:28 <dbungert> are some of them things that also apply to Debian and incorporated in the Debian's version of the packaging?
16:29 <dbungert> sometimes these changes won't be present exactly - for instance maybe a fix was applied upstream but refactored since then, so an understanding of intent is critical rather than looking for literal lines
16:30 <dbungert> with attention to detail we can handle the entire ubuntu changeset and ensure that we keep what is needed and drop what is obsolete or already handled elsewhere
16:30 <rbasak> OK, thanks
16:31 <sil2100> No more questions from me
16:31 <rbasak> Next question: what would you look for in an upload you've prepared to determine if you're about to trigger a transition?
16:31 <dbungert> the stock answer there is soname / api / abi changes
16:31 <kanashiro[m]> during the merge is also a good time to re-evaluate if you can forward any Ubuntu change to Debian or upstream
16:32 <dbungert> I try to think more broadly about package transitions - It's more than just SONAME, as any service one package provides to another could change and cause the other packages that depend upon that service to respond
16:33 <dbungert> if we suspect a transition, test rebuilds are a useful tool
16:33 <rbasak> What do you mean by "to respond"?
16:34 <dbungert> for a time there the 'which' utility was printing a message pointing programs to 'command -v'
16:34 <dbungert> IIRC we backed out that change, but if we proceeded, then all the packages that are using 'which' might want to move over to 'command -v'
16:35 <dbungert> so by 'resond' I mean handle the transition in whatever way is appropriate
16:35 <dbungert> a more standard example, I assisted with ffmpeg 5 things as part of +1
16:35 <dbungert> ffmpeg 5 introduced new APIs and deprecated old ones, so some packages were in a better state than others
16:36 <dbungert> some packages were effectively just starting their movement to the new APIs, some just needed a rebuild
16:36 <rbasak> Let's narrow the scope a bit. Let's limit our discussion of transitions to changes which would cause things to end up "entangled" in proposed migration.
16:36 <rbasak> So that would like exclude the which/command -v thing, if you ignore dep8.
16:37 <rbasak> Can you describe the mechanism by which things get entangled like this, please?
16:37 <dbungert> suppose a package has participates in two transitions at the same time
16:38 <dbungert> perhaps a gcc change that needs to be responded to and a library change like ffmpeg
16:39 <dbungert> the transition tracker can help identify things like this https://people.canonical.com/~ubuntu-archive/transitions/
16:39 <dbungert> I'm not sure what to say from there other than handle all the things
16:39 <dbungert> I can always ask ;)
16:39 <rbasak> During a transition, what is the basic check that blocks a package from migrating to the release pocket?
16:39 <dbungert> autopkgtest helps check such things
16:41 <rbasak> Anything else apart from autopkgtest?
16:41 <dbungert> packages need to be buildable, and the dependencies of the package also need to have migrated
16:42 <rbasak> OK, thanks.
16:42 <rbasak> Let's talk about the release cycle.
16:42 <rbasak> On what date will you stop being able to generally upload feature changes to Kinetic?
16:43 <rbasak> And where do you find this information?
16:43 <dbungert> https://discourse.ubuntu.com/t/kinetic-kudu-release-schedule/27263
16:43 <dbungert> Aug-25 is feature freeze
16:43 <dbungert> the Release category of discouse is a good starting point for this sort of info
16:44 <dbungert> *discourse
16:44 <rbasak> OK. And how do you determine what counts as a feature? For example, let's say that we have packaged 1.2~beta1, and 1.2-final is released upstream. Would that be OK?
16:44 <dbungert> this is always case by case
16:44 <dbungert> upstream changelog can be a good starting point, code review is better
16:45 <rbasak> What would you be looking for exactly?
16:45 <dbungert> in a bugfix release I would be hoping to see links to bug reports
16:45 <dbungert> * fix bug A, * fix bug B, so on
16:45 <dbungert> and the diff should look appropriate for what the changelog says
16:45 <rbasak> What sort of changes would not be acceptable?
16:46 <dbungert> new features usually aren't, though we have an exception process if we\ think we should include them anyhow
16:47 <dbungert> feature vs bug is a favoriate point of argument, we just have to use our jdugement at a certain point
16:47 <rbasak> Where is the exception process documented please?
16:47 <dbungert> https://wiki.ubuntu.com/FreezeExceptionProcess
16:48 <rbasak> OK, thanks.
16:48 * rbasak might have another question; one moment please
16:48 <sil2100> Just a reminder: 12 minutes left to the end of the meeting
16:48 <bdmurray> Is there anybody else nto ready to vote?
16:48 <sil2100> I have to do a hard stop at that time
16:48 <sil2100> I am ready
16:49 <rbasak> I think I'm done. No more questions from me, thanks.
16:49 <bdmurray> #vote Dan Bungert to become an Ubuntu Core Developer
16:49 <meetingology> Please vote on: Dan Bungert to become an Ubuntu Core Developer
16:49 <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')
16:49 <kanashiro[m]> ready to vote
16:49 <rbasak> +1
16:49 <meetingology> +1 received from rbasak
16:49 <bdmurray> +1
16:49 <meetingology> +1 received from bdmurray
16:50 <sil2100> +1
16:50 <meetingology> +1 received from sil2100
16:50 <kanashiro[m]> +1
16:50 <meetingology> +1 received from kanashiro[m]
16:51 <rbasak> I'm a little concerned that you seem to take a different meaning of "transition" from what I think Ubuntu developers would take that to mean, and also that "uninstallability" didn't factor into your answer when that's pretty standard terminology. It might be worth studying up on proposed migration and related mechanisms.
16:51 <rbasak> Also if you do a complex merge then MoM/debdiff is a pretty blunt tool that makes things very difficult. We can do better nowadays.
16:51 <rbasak> But you seem to understand the goal well enough.
16:52 <bdmurray> seb128, teward ?
16:52 <dbungert> rbasak: sure, I will look more into all the above.
16:52 <seb128> +1
16:52 <meetingology> +1 received from seb128
16:52 <teward> +1
16:52 <meetingology> +1 received from teward
16:52 * sil2100 still uses MoM, uh
16:52 <bdmurray> #endvote
16:52 <meetingology> Voting ended on: Dan Bungert to become an Ubuntu Core Developer
16:52 <meetingology> Votes for: 6, Votes against: 0, Abstentions: 0
16:52 <meetingology> Motion carried
16:53 <bdmurray> dbungert: congratulations!
16:53 <dbungert> :tada:
16:53 <sil2100> ...but I guess I got lucky with rather easy merges throughout the recent times
16:53 <sil2100> dbungert: congrats!
16:53 <rbasak> Sorry I did some hard questioning there, but that's the norm for me when jumping straight to core dev from non-uploader which I think you just did? Congrats :)
16:53 <teward> sil2100: at least you didn't get stuck with the mailman3 MIR a while back. *laughs at sarnold's misfortune*
16:53 * sarnold sobs
16:53 <sil2100> hah ;)
16:53 <rbasak> sil2100: use of MoM for complex merges breeds merge errors. I see them all the time (not sure about yours exactly).
16:54 <dbungert> Thanks everyone :)
16:54 <bdmurray> Do the actions fall upon the chair (of the meeting)?
16:54 <sarnold> dbungert: oh wow, congratulations on the upgrade of privs and responsibilities :)
16:54 <rbasak> People generally volunteer.
16:54 <rbasak> Assign them to me if you like.
16:54 <rbasak> And thanks for chairing!
16:54 <teward> but the chair must still update the agenda, etc.
16:54 <teward> and thanks for chaairing ;)
16:54 <bdmurray> The chair can't login to the wiki
16:55 <bdmurray> #action bdmurray to add dbunger to the ubuntu-core-dev team
16:55 * meetingology bdmurray to add dbunger to the ubuntu-core-dev team
16:55 <bdmurray> #action rbasak to announce dbungert's successful application
16:55 * meetingology rbasak to announce dbungert's successful application
16:55 <bdmurray> #topic Review of previous action items
16:56 <bdmurray> 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)
16:56 <bdmurray> teward carrying over this one?
16:56 <teward> yes
16:56 <bdmurray> #topic Outstanding mailing list requests to assign
16:57 <bdmurray> anything there?
16:57 <bdmurray> Doesn't look like it
16:58 <bdmurray> Thanks everyone!
16:58 <bdmurray> #endmeeting