== Meeting information == * #ubuntu-meeting: Developer Membership Board meeting, started by bdmurray, 22 Aug at 16:09 — 16:58 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-22-16.09.log.html == Meeting summary == === Ubuntu Core Developer Applications === Discussion started by bdmurray at 16:10. * ''ACTION:'' bdmurray to check in with fheimes (bdmurray, 16:12) * '''Ubuntu Core Developer Application - Dan Bungert''' (bdmurray, 16:13) * ''LINK:'' https://wiki.ubuntu.com/dbungert/CoreDev (dbungert, 16:13) * ''LINK:'' https://wiki.ubuntu.com/dbungert/CoreDev (bdmurray, 16:15) * ''LINK:'' https://discourse.ubuntu.com/t/kinetic-kudu-release-schedule/27263 (dbungert, 16:43) * ''LINK:'' https://wiki.ubuntu.com/FreezeExceptionProcess (dbungert, 16:47) * ''VOTE:'' Dan Bungert to become an Ubuntu Core Developer (Carried) (bdmurray, 16:52) * ''ACTION:'' bdmurray to add dbunger to the ubuntu-core-dev team (bdmurray, 16:55) * ''ACTION:'' rbasak to announce dbungert's successful application (bdmurray, 16:55) === Review of previous action items === Discussion started by bdmurray at 16:55. === Outstanding mailing list requests to assign === Discussion started by bdmurray at 16:56. == Vote results == * [[https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-22-16.09.log.html#102|Dan Bungert to become an Ubuntu Core Developer]] * Motion carried (For: 6, Against: 0, Abstained: 0) * Voters: rbasak, bdmurray, sil2100, kanashiro[m], seb128, teward == Action items, by person == * bdmurray * bdmurray to check in with fheimes * bdmurray to add dbunger to the ubuntu-core-dev team * dbungert * rbasak to announce dbungert's successful application * rbasak * rbasak to announce dbungert's successful application == People present (lines said) == * dbungert (53) * rbasak (37) * bdmurray (27) * meetingology (16) * sil2100 (13) * teward (6) * kanashiro[m] (3) * sarnold (2) * seb128 (1) == Full log == 16:09 #startmeeting Developer Membership Board 16:09 Meeting started at 16:09:39 UTC. The chair is bdmurray. Information about MeetBot at https://wiki.ubuntu.com/meetingology 16:09 Available commands: action, commands, idea, info, link, nick 16:09 We'll start with applications 16:10 #topic Ubuntu Core Developer Applications 16:10 I believe fheimes application is still outstanding and he applied first 16:11 I don't think he's picked a meeting date to resume his application though? 16:11 IIRC he said he would be out of office at the time. I don't know how long that was for. 16:12 Yeah. SHould we maybe reach out to him with a reminder about that? 16:12 #action bdmurray to check in with fheimes 16:12 * meetingology bdmurray to check in with fheimes 16:13 #subtopic Ubuntu Core Developer Application - Dan Bungert 16:13 dbungert: Could you introduce yourself? 16:13 https://wiki.ubuntu.com/dbungert/CoreDev 16:13 Hi - I am Dan Bungert 16:14 Hello! 16:14 I joined Canonical January of 2021, and have largely been focused on Subiquity and related matters since that time 16:14 I also assist on various Foundations related tasks, as needed to help the release keep moving 16:15 https://wiki.ubuntu.com/dbungert/CoreDev 16:15 Thank you for doing +1 maintenance - I see a lot of sponsored uploads that look like they were related to that. 16:15 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 Merge-o-matic can help with that 16:16 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 Do you know of any packages that you "TIL" that need attention? 16:18 looks like I have 2 right now in Universe 16:18 hydra and oz 16:18 I will address them 16:19 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 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 rbasak: if you're content with the above, shall I do sil2100's question? 16:20 Yes - please go ahead. I think I have a further separate question on merges but I can awk that afterwards. 16:21 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 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 then with some testing, the SRU can proceed 16:22 The wiki has great details on all the above 16:23 Are there some general constraints on what can and cannot be SRUed? 16:24 It's generally not preferred to mass merge an entire upstream release for a SRU. Targetted fixes are preferred instead. 16:24 In some cases there are documented exceptions for that - Curtin has such an exception IIRC 16:24 Okay, thank you 16:25 rbasak: did you have another question? 16:26 o/ (sorry i'm late, neck deep in an Microsoft Active Directory rebuild for a client) 16:26 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 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 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 then review those changes - are some of them upstream things and maybe incoporated in the unpatched upstream version? 16:28 are some of them things that also apply to Debian and incorporated in the Debian's version of the packaging? 16:29 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 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 OK, thanks 16:31 No more questions from me 16:31 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 the stock answer there is soname / api / abi changes 16:31 during the merge is also a good time to re-evaluate if you can forward any Ubuntu change to Debian or upstream 16:32 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 if we suspect a transition, test rebuilds are a useful tool 16:33 What do you mean by "to respond"? 16:34 for a time there the 'which' utility was printing a message pointing programs to 'command -v' 16:34 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 so by 'resond' I mean handle the transition in whatever way is appropriate 16:35 a more standard example, I assisted with ffmpeg 5 things as part of +1 16:35 ffmpeg 5 introduced new APIs and deprecated old ones, so some packages were in a better state than others 16:36 some packages were effectively just starting their movement to the new APIs, some just needed a rebuild 16:36 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 So that would like exclude the which/command -v thing, if you ignore dep8. 16:37 Can you describe the mechanism by which things get entangled like this, please? 16:37 suppose a package has participates in two transitions at the same time 16:38 perhaps a gcc change that needs to be responded to and a library change like ffmpeg 16:39 the transition tracker can help identify things like this https://people.canonical.com/~ubuntu-archive/transitions/ 16:39 I'm not sure what to say from there other than handle all the things 16:39 I can always ask ;) 16:39 During a transition, what is the basic check that blocks a package from migrating to the release pocket? 16:39 autopkgtest helps check such things 16:41 Anything else apart from autopkgtest? 16:41 packages need to be buildable, and the dependencies of the package also need to have migrated 16:42 OK, thanks. 16:42 Let's talk about the release cycle. 16:42 On what date will you stop being able to generally upload feature changes to Kinetic? 16:43 And where do you find this information? 16:43 https://discourse.ubuntu.com/t/kinetic-kudu-release-schedule/27263 16:43 Aug-25 is feature freeze 16:43 the Release category of discouse is a good starting point for this sort of info 16:44 *discourse 16:44 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 this is always case by case 16:44 upstream changelog can be a good starting point, code review is better 16:45 What would you be looking for exactly? 16:45 in a bugfix release I would be hoping to see links to bug reports 16:45 * fix bug A, * fix bug B, so on 16:45 and the diff should look appropriate for what the changelog says 16:45 What sort of changes would not be acceptable? 16:46 new features usually aren't, though we have an exception process if we\ think we should include them anyhow 16:47 feature vs bug is a favoriate point of argument, we just have to use our jdugement at a certain point 16:47 Where is the exception process documented please? 16:47 https://wiki.ubuntu.com/FreezeExceptionProcess 16:48 OK, thanks. 16:48 * rbasak might have another question; one moment please 16:48 Just a reminder: 12 minutes left to the end of the meeting 16:48 Is there anybody else nto ready to vote? 16:48 I have to do a hard stop at that time 16:48 I am ready 16:49 I think I'm done. No more questions from me, thanks. 16:49 #vote Dan Bungert to become an Ubuntu Core Developer 16:49 Please vote on: Dan Bungert to become an Ubuntu Core Developer 16:49 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 ready to vote 16:49 +1 16:49 +1 received from rbasak 16:49 +1 16:49 +1 received from bdmurray 16:50 +1 16:50 +1 received from sil2100 16:50 +1 16:50 +1 received from kanashiro[m] 16:51 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 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 But you seem to understand the goal well enough. 16:52 seb128, teward ? 16:52 rbasak: sure, I will look more into all the above. 16:52 +1 16:52 +1 received from seb128 16:52 +1 16:52 +1 received from teward 16:52 * sil2100 still uses MoM, uh 16:52 #endvote 16:52 Voting ended on: Dan Bungert to become an Ubuntu Core Developer 16:52 Votes for: 6, Votes against: 0, Abstentions: 0 16:52 Motion carried 16:53 dbungert: congratulations! 16:53 :tada: 16:53 ...but I guess I got lucky with rather easy merges throughout the recent times 16:53 dbungert: congrats! 16:53 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 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 hah ;) 16:53 sil2100: use of MoM for complex merges breeds merge errors. I see them all the time (not sure about yours exactly). 16:54 Thanks everyone :) 16:54 Do the actions fall upon the chair (of the meeting)? 16:54 dbungert: oh wow, congratulations on the upgrade of privs and responsibilities :) 16:54 People generally volunteer. 16:54 Assign them to me if you like. 16:54 And thanks for chairing! 16:54 but the chair must still update the agenda, etc. 16:54 and thanks for chaairing ;) 16:54 The chair can't login to the wiki 16:55 #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 #action rbasak to announce dbungert's successful application 16:55 * meetingology rbasak to announce dbungert's successful application 16:55 #topic Review of previous action items 16:56 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 teward carrying over this one? 16:56 yes 16:56 #topic Outstanding mailing list requests to assign 16:57 anything there? 16:57 Doesn't look like it 16:58 Thanks everyone! 16:58 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)