16:25 <rbasak> #startmeeting Developer Membership Board
16:25 <meetingology> Meeting started at 16:25:00 UTC.  The chair is rbasak.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
16:25 <meetingology> Available commands: action, commands, idea, info, link, nick
16:25 <rbasak> I'm going to jump straight to arraybolt3's application so as not to keep him waiting
16:25 <rbasak> #topic Ubuntu MOTU Developer Applications
16:25 <rbasak> #subtopic     ArrayBolt3 2024-01-08
16:25 <rbasak> #link https://wiki.ubuntu.com/ArrayBolt3/MotuApplication
16:26 <rbasak> Welcome arraybolt3!
16:26 <rbasak> Your contribution history looks impressive. Thank you!
16:26 <arraybolt3> o/ Thanks :)
16:27 <rbasak> I will have questions shortly
16:27 <rbasak> Anyone else, feel free
16:29 <rbasak> 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 <arraybolt3> Probably my first step is to look at the reverse depends with apt-cache rdepends.
16:29 <arraybolt3> after that, if there were some reverse depends, I check those reverse depends and so on.
16:29 <arraybolt3> Usually shared libraries are at higher risk of causing these sorts of things than applications.
16:30 <arraybolt3> (shared libraries including things like Python libraries, not necessarily libwhatever1 packages)
16:30 <rbasak> What would you be looking at in the rdepends list?
16:30 <rbasak> s/at/for/
16:30 <arraybolt3> 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 <arraybolt3> ...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 <arraybolt3> I could also check the update excuses page to see if packages that were rdepends were already part of transitions.
16:31 <arraybolt3> Since entangling those could block other transitions and cause Big Problems.
16:31 <arraybolt3> (the page I'm referring to is https://ubuntu-archive-team.ubuntu.com/proposed-migration/update_excuses.html)
16:32 <rbasak> Could you explain to me what you understand a transition to be exactly, please?
16:32 * arraybolt3 opens the Proposed Migration page...
16:33 <arraybolt3> A transition is when a package migrates from -proposed to -release after Britney and autopkgtest verifies that this won't break anything.
16:34 <arraybolt3> (won't break anything = passes all five points at the top of https://wiki.ubuntu.com/ProposedMigration)
16:34 <rbasak> I think you're describing proposed migration as opposed to a transition
16:35 <arraybolt3> 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 <arraybolt3> 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 <rbasak> 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 <rbasak> And you're right that autopkgtest failures hold up proposed migrations
16:37 <rbasak> ie. there are multiple things that hold up proposed migration, and one of those is that there's a transition in progress
16:38 <rbasak> It's possible that you understand what I'm looking for and we're just getting stuck in terminology
16:39 <rbasak> 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 <rbasak> What are the implications of uploading src:foo 2.0, which moves on to libfoo2?
16:39 <rbasak> In relation to proposed migration?
16:40 <arraybolt3> 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 <arraybolt3> in which case you end up with multiple interrelated packages migrating together once everything passes the proposed migration tests.
16:41 <rbasak> Let's pretend that there are no autopkgtests in any of the relevant packages, so nothing is held up by autopkgtest failures
16:41 <arraybolt3> (er, sorry, I mean reverse dependencies when I say entangled packages)
16:41 <rbasak> Why would proposed migration be held up?
16:41 <rbasak> Why would proposed migration _still_ be held up?
16:41 <arraybolt3> Lots of possible reasons: it could no longer build and publish on an architecture it used to...
16:42 <arraybolt3> ...there could be dependency issues that would result in unsatisfied dependencies if the package(s) migrate...
16:42 <rbasak> What dependency issues exactly?
16:42 <rbasak> 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 <arraybolt3> 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 <arraybolt3> so for a concrete example:
16:43 <arraybolt3> src:libfoo 1.0 exists, and package bar 1.0 depends on it.
16:43 <arraybolt3> libfoo2 is uploaded.
16:44 <rbasak> package bar 1.0 depends on what exactly?
16:44 <arraybolt3> bar 1.0 depends on libfoo1.
16:45 <arraybolt3> hold on, I'm getting slightly mixed up
16:45 <arraybolt3> 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 <arraybolt3> 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 <rbasak> 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 <arraybolt3> True.
16:47 <rbasak> 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 <arraybolt3> 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 <rbasak> At least in the common case. I realise an exhaustive search is difficult, but what are the most common indicators?
16:48 <arraybolt3> so if I build libfoo and end up with libfoo2 when I had libfoo1, that's a red flag.
16:48 <rbasak> OK. Thanks!
16:49 <rbasak> My next question was going to be about proposed migration but I think you've covered that enough already :)
16:49 <rbasak> 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 <arraybolt3> 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 <arraybolt3> The freeze exception process is documented at https://wiki.ubuntu.com/FreezeExceptionProcess.
16:51 <arraybolt3> the Release Team are the ones who can ACK an FFe.
16:52 <rbasak> 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 <arraybolt3> 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 <arraybolt3> 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 <arraybolt3> (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 <arraybolt3> (or if they introduce new API at all)
16:56 <arraybolt3> 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 <rbasak> OK. Thanks!
16:58 <rbasak> I'm just looking at your "regular" SRU history
16:58 <rbasak> I only see bug 1989203. Have you done any others?
16:58 <arraybolt3> yes, one sec...
16:59 <arraybolt3> https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2002255
17:00 <arraybolt3> 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 <rbasak> OK. I don't think it's necessary to go deeper.
17:01 <rbasak> 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 <rbasak> I think I'm done with my questions.
17:02 <rbasak> Anyone else?
17:02 <arraybolt3> +1, that's good advice.
17:02 <bdmurray> None from me.
17:02 <rbasak> Shall we move to a vote, even if incomplete, to make some progress for now?
17:02 <teward> none from me
17:02 <rbasak> #vote Grant Aaron Rainbolt MOTU permission
17:02 <meetingology> Please vote on: Grant Aaron Rainbolt MOTU permission
17:02 <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')
17:02 <rbasak> +1
17:02 <meetingology> +1 received from rbasak
17:03 <bdmurray> +1
17:03 <meetingology> +1 received from bdmurray
17:03 <teward> my vote comes last, so seb128 votes ahead of me
17:04 <teward> unless seb128 had to bow out due to COVID
17:04 <teward> +1
17:04 <meetingology> +1 received from teward
17:04 <rbasak> I think we need a vote from seb128 in order to conclude today.
17:05 <teward> yep, we do.  because otherwise we are not quorate.
17:05 <rbasak> 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 <rbasak> for the day / for today :-)
17:06 <seb128> +1
17:06 <meetingology> +1 received from seb128
17:06 <rbasak> Thanks Seb!
17:06 <rbasak> #endvote
17:06 <meetingology> Voting ended on: Grant Aaron Rainbolt MOTU permission
17:06 <meetingology> Votes for: 4, Votes against: 0, Abstentions: 0
17:06 <meetingology> Motion carried
17:07 <seb128> np, sorry for the delay!
17:07 <rbasak> Congratulations arraybolt3!
17:07 <arraybolt3> \o/
17:07 <tsimonq2> CONGRATULATIONS arraybolt3!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉
17:07 <rbasak> And thank you for all your work
17:07 <arraybolt3> Thank you!
17:07 <rbasak> #action rbasak to add arraybolt3 to MOTU
17:07 * meetingology rbasak to add arraybolt3 to MOTU
17:07 <leokolb> Congrats Aaron!
17:07 <rbasak> #action rbasak to announce arraybolt3's successful application
17:07 * meetingology rbasak to announce arraybolt3's successful application
17:07 <Eickmeyer> 🥳
17:08 <rbasak> We're over time, so I'll skip the other items for now, unless there's anything urgent?
17:08 <rbasak> #topic AOB
17:08 <tsimonq2> rbasak: ...where's kanashiro and Utkarsh?
17:09 <tsimonq2> That's my only question, and it can be punted.
17:09 <rbasak> I suspect they're still off from the break period
17:10 <tsimonq2> Okay. :)
17:10 <rbasak> I know DMB attendence is not necessarily a Canonical function, but people are still allowed time off :-)
17:10 <rbasak> #endmeeting