== Meeting information == * #ubuntu-meeting: Developer Membership Board meeting, started by rbasak, 08 Jan at 16:25 — 17:10 UTC. * Full logs at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-01-08-16.25.log.html == Meeting summary == === Ubuntu MOTU Developer Applications === Discussion started by rbasak at 16:25. * '''ArrayBolt3 2024-01-08''' (rbasak, 16:25) * ''LINK:'' https://wiki.ubuntu.com/ArrayBolt3/MotuApplication (rbasak, 16:25) * ''LINK:'' https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2002255 (arraybolt3, 16:59) * ''VOTE:'' Grant Aaron Rainbolt MOTU permission (Carried) (rbasak, 17:06) * ''ACTION:'' rbasak to add arraybolt3 to MOTU (rbasak, 17:07) * ''ACTION:'' rbasak to announce arraybolt3's successful application (rbasak, 17:07) === AOB === Discussion started by rbasak at 17:08. == Vote results == * [[https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-01-08-16.25.log.html#90|Grant Aaron Rainbolt MOTU permission]] * Motion carried (For: 4, Against: 0, Abstained: 0) * Voters: rbasak, bdmurray, teward, seb128 == Action items, by person == * arraybolt3 * rbasak to add arraybolt3 to MOTU * rbasak to announce arraybolt3's successful application * rbasak * rbasak to add arraybolt3 to MOTU * rbasak to announce arraybolt3's successful application == People present (lines said) == * rbasak (58) * arraybolt3 (45) * meetingology (13) * teward (5) * tsimonq2 (4) * bdmurray (2) * seb128 (2) * leokolb (1) * Eickmeyer (1) == Full log == 16:25 #startmeeting Developer Membership Board 16:25 Meeting started at 16:25:00 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology 16:25 Available commands: action, commands, idea, info, link, nick 16:25 I'm going to jump straight to arraybolt3's application so as not to keep him waiting 16:25 #topic Ubuntu MOTU Developer Applications 16:25 #subtopic ArrayBolt3 2024-01-08 16:25 #link https://wiki.ubuntu.com/ArrayBolt3/MotuApplication 16:26 Welcome arraybolt3! 16:26 Your contribution history looks impressive. Thank you! 16:26 o/ Thanks :) 16:27 I will have questions shortly 16:27 Anyone else, feel free 16:29 arraybolt3: let's say that you're about to upload a package merge from Debian and it's a couple of days before feature freeze. How would you check, technically, that you're not about to inadvertently trigger a large transition? 16:29 Probably my first step is to look at the reverse depends with apt-cache rdepends. 16:29 after that, if there were some reverse depends, I check those reverse depends and so on. 16:29 Usually shared libraries are at higher risk of causing these sorts of things than applications. 16:30 (shared libraries including things like Python libraries, not necessarily libwhatever1 packages) 16:30 What would you be looking at in the rdepends list? 16:30 s/at/for/ 16:30 mainly to see how big the network of rdepends is. One or two might not be a huge deal depending on what those one or two are... 16:31 ...but if there's a large network of them then I know to exercise caution and potentially not attempt the process at all. 16:31 I could also check the update excuses page to see if packages that were rdepends were already part of transitions. 16:31 Since entangling those could block other transitions and cause Big Problems. 16:31 (the page I'm referring to is https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html) 16:32 Could you explain to me what you understand a transition to be exactly, please? 16:32 * arraybolt3 opens the Proposed Migration page... 16:33 A transition is when a package migrates from -proposed to -release after Britney and autopkgtest verifies that this won't break anything. 16:34 (won't break anything = passes all five points at the top of https://wiki.ubuntu.com/ProposedMigration) 16:34 I think you're describing proposed migration as opposed to a transition 16:35 for some reason I didn't realize there was a difference, we call it a "python3 transition" when the python3-default package is uploaded. 16:36 since that triggers a whole web of autopkgtests and if any of those fail, then the package is blocked and the failures need to be fixed before the transition can migrate 16:36 It's true that a transition should hold up proposed migration until it is complete, so the two concepts are very closely linked. 16:37 And you're right that autopkgtest failures hold up proposed migrations 16:37 ie. there are multiple things that hold up proposed migration, and one of those is that there's a transition in progress 16:38 It's possible that you understand what I'm looking for and we're just getting stuck in terminology 16:39 Let's say that src:foo 1.0 is in the archive, and it produces binary packages libfoo1 which various packages depend on, and libfoo-dev which those packages build depend on. 16:39 What are the implications of uploading src:foo 2.0, which moves on to libfoo2? 16:39 In relation to proposed migration? 16:40 API breaking changes which would very likely cause autopkgtest failures due to the need for the entangled packages to be updated to use the new API. 16:40 in which case you end up with multiple interrelated packages migrating together once everything passes the proposed migration tests. 16:41 Let's pretend that there are no autopkgtests in any of the relevant packages, so nothing is held up by autopkgtest failures 16:41 (er, sorry, I mean reverse dependencies when I say entangled packages) 16:41 Why would proposed migration be held up? 16:41 Why would proposed migration _still_ be held up? 16:41 Lots of possible reasons: it could no longer build and publish on an architecture it used to... 16:42 ...there could be dependency issues that would result in unsatisfied dependencies if the package(s) migrate... 16:42 What dependency issues exactly? 16:42 My example is the common case of a completely routine transition, so my expectation is that you should be able to follow and give me the specific dependency issue that would hold things up 16:43 Anything that would cause apt to be unable to install the package were it in the archive, i.e. a dependency is missing or the proper version isn't available because (for instance) one of the reverse depends isn't updated to use the new version of the library. 16:43 so for a concrete example: 16:43 src:libfoo 1.0 exists, and package bar 1.0 depends on it. 16:43 libfoo2 is uploaded. 16:44 package bar 1.0 depends on what exactly? 16:44 bar 1.0 depends on libfoo1. 16:45 hold on, I'm getting slightly mixed up 16:45 so src:libfoo 1.0 is uploaded, bar 1.0 is uploaded which has a Depends: libfoo1 (= 1.0), then src:libfoo 2.0 is uploaded. 16:46 now bar 1.0 can no longer satisfy its dependency, so bar 2.0 has to be uploaded also before they can migrate together. 16:47 OK I think you have enough of an understanding there. Though note that a straight rebuild of bar 1.0 might be sufficient, since it's the ABI that changed, and it's possible that the API remains the same or that bar uses a small enough subset that it works without changes against foo 2. 16:47 True. 16:47 So, going back a few steps, what exactly would you be looking for to see if you're going to inadvertently trigger this kind of situation? 16:48 ah, I get it better now. Soname bumps mainly, but also versioned Depends since it's not just shared objects that can cause transitions. 16:48 At least in the common case. I realise an exhaustive search is difficult, but what are the most common indicators? 16:48 so if I build libfoo and end up with libfoo2 when I had libfoo1, that's a red flag. 16:48 OK. Thanks! 16:49 My next question was going to be about proposed migration but I think you've covered that enough already :) 16:49 Next question: when is feature freeze for Noble, where would I look up that information, and who can authorise an exception and where is that process documented? 16:50 The page where the freezes are documented for Noble is at https://discourse.ubuntu.com/t/noble-numbat-release-schedule/35649. According to that calendar, Feature Freeze is February 29, 2024. 16:51 The freeze exception process is documented at https://wiki.ubuntu.com/FreezeExceptionProcess. 16:51 the Release Team are the ones who can ACK an FFe. 16:52 Let's say that you'd like to upload new upstream release of foo 1.2.2, and 1.2.1 is currently in the archive, and it's March 1st. Is that acceptable? Or if that's not enough information, what extra information do you need to make a decision? 16:53 Not enough information - what versioning scheme does foo 1.2.2 use? Is is a purely bugfix release? Or could it incorporate new features or breaking changes? 16:54 Assuming it uses semver, an upload of 1.2.2 is *probably* OK since 1.2.1 -> 1.2.2 is a patch release. 16:55 (I say probably since upstream might not strictly adhere to the rule of only making backwards-compatible bug fixes in a patch release, if they do make breaking API changes that's still a no-no) 16:55 (or if they introduce new API at all) 16:56 if for some reason the patch release is really important and isn't suitable for introduction after Feature Freeze, then I would either backport the parts of the release that are Feature Freeze compatible that I need, or request an FFe if necessary. That would have to be decided on a case-by-case basis. 16:57 OK. Thanks! 16:58 I'm just looking at your "regular" SRU history 16:58 I only see bug 1989203. Have you done any others? 16:58 yes, one sec... 16:59 https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2002255 17:00 I've written SRU paperwork for other SRUs before but I can't remember any other ones I've done myself other than this one. This one I wrote the code for, wrote the paperwork for, did the testing for, etc, and everything went as planned. 17:00 OK. I don't think it's necessary to go deeper. 17:01 Just one comment, DMB meeting aside: please specify what package version you tested in your SRU verification report. We've had serious regressions in the past due to oversight/ambiguity there. 17:01 I think I'm done with my questions. 17:02 Anyone else? 17:02 +1, that's good advice. 17:02 None from me. 17:02 Shall we move to a vote, even if incomplete, to make some progress for now? 17:02 none from me 17:02 #vote Grant Aaron Rainbolt MOTU permission 17:02 Please vote on: Grant Aaron Rainbolt MOTU permission 17:02 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') 17:02 +1 17:02 +1 received from rbasak 17:03 +1 17:03 +1 received from bdmurray 17:03 my vote comes last, so seb128 votes ahead of me 17:04 unless seb128 had to bow out due to COVID 17:04 +1 17:04 +1 received from teward 17:04 I think we need a vote from seb128 in order to conclude today. 17:05 yep, we do. because otherwise we are not quorate. 17:05 He did say he's ill, so let's give him five minutes. If he's unable to vote by then, we'll close for the today and move to the mailing list. 17:05 for the day / for today :-) 17:06 +1 17:06 +1 received from seb128 17:06 Thanks Seb! 17:06 #endvote 17:06 Voting ended on: Grant Aaron Rainbolt MOTU permission 17:06 Votes for: 4, Votes against: 0, Abstentions: 0 17:06 Motion carried 17:07 np, sorry for the delay! 17:07 Congratulations arraybolt3! 17:07 \o/ 17:07 CONGRATULATIONS arraybolt3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉 17:07 And thank you for all your work 17:07 Thank you! 17:07 #action rbasak to add arraybolt3 to MOTU 17:07 * meetingology rbasak to add arraybolt3 to MOTU 17:07 Congrats Aaron! 17:07 #action rbasak to announce arraybolt3's successful application 17:07 * meetingology rbasak to announce arraybolt3's successful application 17:07 🥳 17:08 We're over time, so I'll skip the other items for now, unless there's anything urgent? 17:08 #topic AOB 17:08 rbasak: ...where's kanashiro and Utkarsh? 17:09 That's my only question, and it can be punted. 17:09 I suspect they're still off from the break period 17:10 Okay. :) 17:10 I know DMB attendence is not necessarily a Canonical function, but people are still allowed time off :-) 17:10 #endmeeting Generated by MeetBot 0.4.0 (https://wiki.ubuntu.com/meetingology)