| dbungert | o/ | 16:00 |
|---|---|---|
| sil2100 | o/ | 16:00 |
| rbasak | o/ | 16:01 |
| * kanashiro[m] waves | 16:01 | |
| seb128 | hey | 16:01 |
| bdmurray | o/ | 16:01 |
| rbasak | Any volunteers to chair? | 16:03 |
| sil2100 | Who wants to chair today? I'd prefer not to as I chaired last time | 16:04 |
| seb128 | not me if possible, that time is inconvenient and while I'm joining I might get interrupted at times | 16:06 |
| sil2100 | kanashiro[m], bdmurray ? | 16:09 |
| sil2100 | I wouldn't want our candidate to have to wait too long for their application to be handled | 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:09 |
| bdmurray | #topic Ubuntu Core Developer Applications | 16:10 |
| bdmurray | I believe fheimes application is still outstanding and he applied first | 16:10 |
| 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:11 |
| 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 | ACTION: bdmurray to check in with fheimes | 16:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| rbasak | Do you know of any packages that you "TIL" that need attention? | 16:17 |
| dbungert | looks like I have 2 right now in Universe | 16:18 |
| dbungert | hydra and oz | 16:18 |
| dbungert | I will address them | 16:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| sil2100 | Are there some general constraints on what can and cannot be SRUed? | 16:23 |
| 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:24 |
| bdmurray | rbasak: did you have another question? | 16:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| dbungert | if we suspect a transition, test rebuilds are a useful tool | 16:33 |
| rbasak | What do you mean by "to respond"? | 16:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| dbungert | perhaps a gcc change that needs to be responded to and a library change like ffmpeg | 16:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| dbungert | new features usually aren't, though we have an exception process if we\ think we should include them anyhow | 16:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| sil2100 | +1 | 16:50 |
| meetingology | +1 received from sil2100 | 16:50 |
| kanashiro[m] | +1 | 16:50 |
| meetingology | +1 received from kanashiro[m] | 16:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| bdmurray | #action bdmurray to add dbunger to the ubuntu-core-dev team | 16:55 |
| meetingology | ACTION: bdmurray to add dbunger to the ubuntu-core-dev team | 16:55 |
| bdmurray | #action rbasak to announce dbungert's successful application | 16:55 |
| meetingology | ACTION: rbasak to announce dbungert's successful application | 16:55 |
| bdmurray | #topic Review of previous action items | 16:55 |
| 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:56 |
| bdmurray | anything there? | 16:57 |
| bdmurray | Doesn't look like it | 16:57 |
| bdmurray | Thanks everyone! | 16:58 |
| bdmurray | #endmeeting | 16:58 |
| meetingology | Meeting ended at 16:58:05 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-22-16.09.moin.txt | 16:58 |
| kanashiro[m] | thanks for chairing bdmurray | 16:59 |
| kanashiro[m] | I can try it next time | 16:59 |
| sil2100 | THanks bdmurray ! | 16:59 |
| utkarsh2102 | aaaaaah. I missed today. | 17:04 |
| utkarsh2102 | and I was here. Ughhhh. | 17:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!