=== jibel_ is now known as jibel === lan3y is now known as laney === Fatal_Sushi is now known as Maik === genii-core is now known as genii [19:00] o/ [19:00] o/ [19:00] o/ [19:01] o/ [19:02] yay! Who's the designated chair for today btw.? [19:02] hm, per the agenda this should be Eric, but I don't know if he's around [19:03] Next is Thomas, also not present, which leaves me [19:03] #startmeeting Developer Membership Board meeting [19:03] Meeting started at 19:03:42 UTC. The chair is sil2100. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:03] Available commands: action, commands, idea, info, link, nick [19:04] #topic Review of previous action items [19:04] ddstreet to handle "Making it easier for applicants to request special meeting times and/or applying by email" [19:04] I got lost in time and space, what's the status of that one? ddstreet ^ ? [19:05] i think that was started in email to the list, but few responses [19:06] #link https://lists.ubuntu.com/archives/devel-permissions/2021-November/001822.html [19:06] Ok, so let me take a look at that one and follow up myself, and carry over the item to the next meeting [19:07] #action ddstreet to handle "Making it easier for applicants to request special meeting times and/or applying by email" (carried over) [19:07] ACTION: ddstreet to handle "Making it easier for applicants to request special meeting times and/or applying by email" (carried over) [19:07] Guess we could rename the item, but it's too late now! ;) [19:07] i believe myself, rbasak, and rafaeldtinoco have provided opinion to either my email or the original one (linked to in my email) [19:07] so yeah if you (and anyone else interested) can review and respond would be great [19:08] I did, I'm +1 of having votes by email by default [19:08] and having the meeting if specifically requested [19:08] One more item to make sure that it's done is that I handled all Simon's MOTU permissions and announcements, so I'll scratch him off the agenda [19:08] Ok, I'll throw my 5 cents there then as well [19:09] #topic Ubuntu Core Developer Applications [19:09] #subtopic William Wilson for core-dev (jawn-smith) [19:09] o/ [19:09] #link https://wiki.ubuntu.com/jawn-smith/CoreDeveloperApplication [19:10] I think jawn-smith already introduced himself last time, but not sure if everyone was present - could you give us a quick re-introduction? [19:10] Absolutely! [19:11] I'm William Wilson, and I'm applying for core-dev. I live in Dallas, TX, and have been on the Foundations team since early January. [19:11] Since my last application I have taken some actions to improve my ability to contribute to Ubuntu as a core-dev. [19:12] The most actionable feedback I received was to get more SRU experience. You will see in my application that I have worked on some SRU patches and filling out the templates. [19:12] and you got 2 recent shifts in +1 maintenance (good) [19:13] As for the feedback about working with non foundations team members, I have worked with till-kamppeter a bit on some of the SRUs, and have frequently asked for reviews in #ubuntu-devel [19:13] I've also been reading documentation and have finished the Go 1.17 transition. [19:14] o/ [19:14] I found the previous meeting logs at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-09-20-15.01.log.html [19:14] Okay, questions? [19:15] rbasak: thank you, very helpful [19:15] I'd basically like to ask the same questions I did last time, but I'd like to save us the trouble of jumping through the same hoops while I restate the same questions, etc. [19:15] So jawn-smith, I wonder if you'd like to elaborate/amend your previous answers for me, please? [19:16] Let's start with transitions. How would you identify that a transition might be triggered before an upload? [19:16] Sure thing! [19:17] Some packages are very obvious that they may cause a transition, such as toolchain packages, openSSL, etc. Beyond that, I would check a few things to identify if a transition might be triggered: [19:18] 1) if the new package upload changes an ABI without change in API [19:19] 2) if the new package upload includes a change of ABI and API [19:19] 3) if the package itself has many reverse build dependencies, it would be worthwhile to do some rebuilds against the new package in a PPA to identify if there are ABI/API changes that hadn't already been noticed [19:21] Let's use openssl as a concrete example. What's the key thing to look for in openssl, before you upload it, that would confirm that a transition will occur - in the common case? [19:22] (by common case I mean that you can assume that everything is being done properly by upstream and by the Debian packager, etc, so you don't need to consider weird cases) [19:23] OpenSSL v3 has a number of API/ABI changes. If you look at changes in the header files you will notice that quite a few of the functions in OpenSSL v2 have been removed altogether. [19:24] In addition, and probably the most obvious thing to check is that the names of libraries have changed [19:24] I'm asking for the key thing you can identify just by looking at the source package and the build of the source package, without any need to look deeper into the source. [19:24] "names of libraries have changed" is close. Can you be more specific? [19:25] Ah I think I understand. The packages themselves that are produced by the new openssl would be different. For example, a new openssl may no longer produce libopenssl1.1-dev, and will instead produce libopenssl3-dev [19:25] You're thinking along the right lines. [19:26] Seeing that those packages had changed would imply that the shared libraries had changed as well [19:27] What about a different source package where the -dev package name isn't versioned. Consider some model library package src:foo that ships libfoo-dev. AFter a transition, it'd still ship libfoo-dev. What else can you look at to determine that a transition will occur? [19:27] which would indicate that a transition would be likely [19:30] Trying to make sure I understand the question correctly [19:32] in this case, libfoo-dev doesn't change version numbers, but can I assume that src:foo also produces binary packages? [19:33] Right [19:35] So in the case of openssl again there is libssl1.1 that becomes deprecated for libopenssl3, which would indicate a change in runtime dependencies (rather than build dependencies) that could trigger a transition [19:35] s/libopenssl3/libssl3 [19:35] jawn-smith: are you aware on how code relocation works and symbols versioning ? [19:36] what can you tell on top of what rbasak is asking, with that in mind. [19:36] So assuming src:foo previously built libfoo1, if it suddently built libfoo1.1 I would know that a transition would be triggered [19:38] jawn-smith: when you're done with other questions, can you tell me what kind of work did you do on the golang-1.17 transition? [19:39] Thanks. I'm done with my question about transitions, but I have further questions when rafaeldtinoco and sil2100 are done on this topic. [19:39] rafaeldtinoco: I feel I have a general understanding, that when creating position-independent executables a symbols table is needed to point to the correct runtime addresses. [19:40] great, feel free to move to sil2100's question please [19:41] sil2100: for the Go 1.17 transition I was aware that it would trigger a transition, so I created a PPA with golang-defaults pointing to Go 1.17 [19:42] I then created another PPA that had a dependency on my golang-defaults 1.17 PPA [19:42] I used the ubuntu-archive-tools to copy every package that appeared in `reverse-depends -b src:golang-defaults` [19:43] Thereby rebuilding all of the golang packages against Go 1.17. [19:43] I then created a list of all of the packages that had build/test failures with Go 1.17, and compared it to the list of packages that were experiencing build/test failures with Go 1.16 [19:44] I determined that the number of new failures was very small and only affected universe packages, and nothing critical. [19:45] I then had a core-dev sponsor golang-defaults 1.17 for me, and worked on fixing some of the new build/test failures in universe packages as part of my +1 maintenance shifts [19:45] jawn-smith: ok, thanks o/ [19:45] I believe rbasak had some more questions :) [19:45] OK so my next question from last time was about disagreements. What's the appropriate escalation point to use if multiple Ubuntu uploaders to a particular package have a disagreement and have been unable to reach consensus on a particular technical point following discussion? [19:46] The Ubuntu technical board [19:46] https://wiki.ubuntu.com/TechnicalBoard [19:46] Great :) [19:46] ;) [19:47] OK, finally, on seeds. libx11-6 is a package needed to run a desktop environment, but I don't think it appears in the desktop seed. Why not? [19:47] Because seeds expand recursively to include their dependencies [19:47] meaning that some other package in the desktop seed would depend on libx11-6 [19:48] maybe not directly, but there would be a chain of dependencies from a package in the desktop seed to libx11-6 [19:49] OK. And when the release team say that the archive is in freeze for seeded packages, but unseeded packages can still be uploaded, then how would you identify if a particular package is seeded or unseeded? [19:49] I would use the command line tool `seeded-in-ubuntu` [19:49] Great! [19:50] Thank you for your patience! I have no further questions. [19:50] Any other questions? [19:50] nope [19:50] ddstreet: ? [19:50] no q [19:51] #vote Grant William 'jawn-smith' Wilson ubuntu-core-developer [19:51] Please vote on: Grant William 'jawn-smith' Wilson ubuntu-core-developer [19:51] 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') [19:51] +1 already voted on mailing list [19:51] +1 already voted on mailing list received from ddstreet [19:51] +1 thank you for reapplying! [19:51] +1 thank you for reapplying! received from rbasak [19:51] +1 [19:51] +1 received from sil2100 [19:52] +1 nice to have you applying. very nice that you have addressed things that were asked to you in the previous application. please make sure to always contribute in other places (rather than foundational packages only). [19:52] +1 nice to have you applying. very nice that you have addressed things that were asked to you in the previous application. please make sure to always contribute in other places (rather than foundational packages only). received from rafaeldtinoco [19:52] FTR, libfoo1 -> libfoo1.1 would be quite unusual, though I appreciate that openssl is an example of that unusual-ness. Normally a corresponding soname would remain at libfoo1 for 1.1, shipping a libfoo.so.1 -> libfoo.so.1.1 and adding new features while maintaining ABI. [19:53] I obviously endorsed jawn-smith as we're closly working together, but I also know that even if in doubt about anyting, William will never be afraid to ask for guidance [19:53] #endvote [19:53] Voting ended on: Grant William 'jawn-smith' Wilson ubuntu-core-developer [19:53] Votes for: 4, Votes against: 0, Abstentions: 0 [19:53] Motion carried [19:53] jawn-smith: congratulations! [19:53] jawn-smith: welcome to the team [19:53] Congratulations! [19:53] woohoo! Thank you everyone! [19:54] congrats! [19:54] I'll take the action item to add jawn-smith to the team, so that we can now put more reposibilities on his shoulders - I'm pretty sure he's very happy about that! [19:54] ;) [19:54] =) [19:54] I sure am! [19:54] #action sil2100 to add jawn-smith to core-dev [19:54] ACTION: sil2100 to add jawn-smith to core-dev [19:54] #action sil2100 to announce jawn-smith's successful application [19:54] ACTION: sil2100 to announce jawn-smith's successful application [19:55] #topic Outstanding mailing list requests to assign [19:55] wasn't there another application ? [19:55] I think that's for a future meeting [19:55] rafaeldtinoco: no, I think Paride is set for the next meeting [19:55] ah ok, my bad [19:55] (damn, I read all his application as well, ready for the next one I guess) [19:55] =o) [19:56] Anyway, as for ML requests, I suppose there's no immediate actions here, I certainly need to follow up on the one re: application via e-mail [19:56] in the agenda wiki page, the quorum rule ML item is done [19:57] but i'd like to ask for a vote on the DMB meeting day/time change, at least 'part 1' of it? [19:57] ACK, and about the new meeting time, are we still waiting on some DMB members to state their availability? [19:57] Ah, we didn't vote yet? [19:57] no we've got that (mostly), the proposal is to change the existing meetings that are at 15:00 UTC to 16:00 UTC, leaving the 19:00 UTC meetings unchanged [19:58] Ok, let's vote in that case [19:58] #vote Vote to change the existing 15:00 UTC meetings to 16:00 UTC (leaving the other, alterating ones as they are) [19:58] Please vote on: Vote to change the existing 15:00 UTC meetings to 16:00 UTC (leaving the other, alterating ones as they are) [19:58] 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') [19:58] One question - have we identified who that will actually benefit? [19:58] +1 [19:58] +1 received from sil2100 [19:58] +1 [19:58] +1 received from ddstreet [19:59] IOW, are there members who prefer this change and expect to be able to make more meetings? [19:59] rbasak i know rafaeldtinoco should benefit from the adjustment, at least [19:59] +1 [19:59] +1 received from rafaeldtinoco [19:59] all the specific details of who wants what times are in the ML thread [20:00] rafaeldtinoco: ^ can you confirm that please? I just want to make sure there's no confusion and someone will actually benefit from the change. [20:00] rbasak: yes, with this change Ill be able to join 2x more meetings (likely) [20:00] Great! In that case... [20:00] +1 [20:00] +1 received from rbasak [20:00] thanks rbasak ! [20:00] #endvote [20:00] Voting ended on: Vote to change the existing 15:00 UTC meetings to 16:00 UTC (leaving the other, alterating ones as they are) [20:00] Votes for: 4, Votes against: 0, Abstentions: 0 [20:00] Motion carried [20:00] And thanks again to ddstreet for organising rescheduling. [20:00] sure, np [20:00] +1 on ddstreet organizing the discussion [20:00] ;) [20:01] and there was some discussion on the list about whether we should move the 19:00 meetings too, can you add an action item for me to follow up on that on the ML? [20:01] Ok, is this enough votes for us to change the schedule in that case? I suppose I can change the agenda then [20:01] Yes 4 is enough. [20:01] (it's an absolute majority) [20:01] #action ddstreet to follow up on if we should change the 19:00 UTC meetings as well [20:01] ACTION: ddstreet to follow up on if we should change the 19:00 UTC meetings as well [20:01] #topic AOB [20:01] Ok, since we're past our time, any other business? [20:02] sil2100 do you want to add an action for yourself to adjust the agenda mtg times? [20:02] on the agenda page i mean [20:02] I wanted to just do this straight after the meeting [20:02] But maybe an action item won't hurt [20:02] ack good enough [20:02] either way :) [20:02] ...just in case I get abducted right after the meeting [20:02] #action sil2100 to change the 15:00 UTC meeting times to 16:00 UTC (on Agenda and calendar) [20:02] ACTION: sil2100 to change the 15:00 UTC meeting times to 16:00 UTC (on Agenda and calendar) [20:03] Going once... [20:03] Going twice... [20:03] #endmeeting [20:03] Meeting ended at 20:03:20 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-11-29-19.03.moin.txt [20:03] thanks all o/ [20:03] ...sorry for hasting at the end! [20:03] o/ [20:03] Thanks everyone! [20:03] sil2100: thank you! [20:30] sil2100: sorry I was not here - FT job email emergency [20:30] that led me to being on the line with them for an hour