[14:07] <arraybolt3> !ping
[14:07] <arraybolt3> (just testing to make sure I won't have technical difficulties when the meeting starts)
[15:59] <arraybolt3> o/
[16:00] <tsimonq2> o/
[16:01] <Eickmeyer> o/
[16:02] <leokolb> o/
[16:02] <teward> *burps loudly on entry*
[16:02] <seb128> hey, I'm off work today (covid) but will be around to try to vote if I'm needed to have a quorum
[16:03] <teward> seb128: you might be, i'm abstaining on any vote on arraybolt unless *I* am needed because otherwise there's bias in my vote.
[16:03] <teward> :P
[16:04] <teward> without you and I we aren't quorate though
[16:04] <teward> though we aren't quorate anyways
[16:04] <arraybolt3> two does not a quorum make :P
[16:04] <teward> need 4 to be quorate, and there are 0 voting members of the DMB present it seems
[16:04] <bdmurray> I'm here but in another meeting
[16:04] <bdmurray> I've heard sil_2100 is out
[16:05] <rbasak> Ah sorry o/
[16:05] <tsimonq2> Whew. :)
[16:06] <arraybolt3> I already have my Wiki page and introduction note prepped, so I should be able to move forward quickly once we start.
[16:07] <rbasak> Sorry I hope to be more available in a few minutes
[16:12] <rbasak> Am I the only voting person who will actually be here then?
[16:12] <arraybolt3> :shrug: grill now and vote later I guess?
[16:12] <bdmurray> I'm able to vote although I'm in another meeting
[16:13] <rbasak> Well I quite strongly request IRC meetings, so I guess I should ask the questions rather than defer then.
[16:13] <arraybolt3> Does anyone actually mind if teward votes? I trust he's not going to risk the safety of the archive to make me happy, and I'm guessing he has questions ready.
[16:13] <tsimonq2> I think he *should* vote, because I don't see a single package on your list that he's sponsored. ;P
[16:13] <arraybolt3> but in any event, if the vote happens later that's not an issue
[16:13] <bdmurray> I don't mind.
[16:14] <rbasak> I know of no specific reason he shouldn't.
[16:15] <seb128> I'm fine with him voting
[16:17] <tsimonq2> (#startmeeting? :))
[16:18]  * arraybolt3 waits for teward to emerge back from the black hole he appears to have vanished into
[16:18] <teward> i have a flurry of C-level execs calling me right now unexpectedly
[16:19] <arraybolt3> well tell them all to wait a sec! :P /s
[16:19] <teward> *throws arraybolt3 out the airlock*
[16:19] <teward> i can vote, but we need quorum
[16:19] <arraybolt3> teward: we have quorum
[16:19] <tsimonq2> teward: We *have* quorum.
[16:19] <arraybolt3> there's four people here.
[16:19] <arraybolt3> you, seb128, rbasak, and bdmurray
[16:19] <teward> bd, robie, me, and seb (if seb's alive) count
[16:19] <arraybolt3> and there's only seven people on the board
[16:20] <teward> i'm aware, but i'm just making that point that I don't know if seb is still around, but i can see he is
[16:20] <teward> i'm alive and we have quorum so
[16:20] <rbasak> Sorry for my slowness. I'm a bit thrown by this being the first week after the break.
[16:20] <rbasak> I would like to be more prepared, but I'm not.
[16:20] <teward> rbasak: welcome to my world.  *slides a coffee*
[16:20] <Eickmeyer> Seriously? <seb128> hey, I'm off work today (covid) but will be around to try to vote if I'm needed to have a quorum
[16:20] <rbasak> But I think I should still do this now, since you're owed that.
[16:20] <Eickmeyer> DMB is an Ubuntu function, not a Canonical function.
[16:20] <tsimonq2> rbasak: Understandable, thanks for clarifying. :)
[16:21] <teward> Eickmeyer: you can cut that line of thinking/discussion right there
[16:21] <teward> and i say that with the CC hat on :\
[16:21] <teward> (stop opening random cans of worms unless you want me as an enemy)
[16:21] <tsimonq2> Okay, let's *NOT* do this now, and actually start the meeting, please.
[16:22] <Eickmeyer> I was just saying that because he said he's here.
[16:22] <teward> i can't chair from my phone sanely, who's gonna chair
[16:22] <rbasak> I can, but I'm also reviewing the application as fast as I can.
[16:23] <teward> someone send me the link again for it?
[16:23] <teward> (so i can rereview it)
[16:24] <arraybolt3> https://ftp-master.debian.org/NEW-checklist.html
[16:24] <arraybolt3> no
[16:24] <arraybolt3> https://wiki.ubuntu.com/ArrayBolt3/MotuApplication
[16:24] <arraybolt3> but now you know what I have prepared for the meeting :P
[16:24] <tsimonq2> :D
[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:44] <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] -ubottu:#ubuntu-meeting- Bug 1989203 in manuskript (Debian) "Manuskript crashes on start" [Unknown, New] https://launchpad.net/bugs/1989203
[16:58] <arraybolt3> yes, one sec...
[16:59] <arraybolt3> https://bugs.launchpad.net/ubuntu/+source/lubuntu-update-notifier/+bug/2002255
[16:59] -ubottu:#ubuntu-meeting- Launchpad bug 2002255 in lubuntu-update-notifier (Ubuntu Jammy) "lubuntu-update-notifier provides no good way to resolve a forcibly terminated system update" [Critical, Fix Released]
[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> ACTION: 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> ACTION: 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
[17:10] <meetingology> Meeting ended at 17:10:40 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2024/ubuntu-meeting.2024-01-08-16.25.moin.txt
[17:10] <tsimonq2> Oh, absolutely. I just haven't seen them in a while and want to make sure they're okay. :)
[17:10] <bdmurray> Especially if they are ill. Thanks for turning up seb128
[17:10] <tsimonq2> ^^^^ seb128 you came in clutch :)
[17:11] <Eickmeyer> <3 seb128
[17:12] <arraybolt3> Thank you all!
[17:14] <arraybolt3> hopping from Konversation back to my bouncer
[17:18] <teward> and i'm going back to the metric ton of crap i have to deal with @ work