19:03 <sil2100> #startmeeting Developer Membership Board meeting
19:03 <meetingology> Meeting started at 19:03:42 UTC.  The chair is sil2100.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
19:03 <meetingology> Available commands: action, commands, idea, info, link, nick
19:04 <sil2100> #topic Review of previous action items
19:04 <sil2100> ddstreet to handle "Making it easier for applicants to request special meeting times and/or applying by email"
19:04 <sil2100> I got lost in time and space, what's the status of that one? ddstreet ^ ?
19:05 <ddstreet> i think that was started in email to the list, but few responses
19:06 <ddstreet> #link https://lists.ubuntu.com/archives/devel-permissions/2021-November/001822.html
19:06 <sil2100> 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 <sil2100> #action ddstreet to handle "Making it easier for applicants to request special meeting times and/or applying by email"  (carried over)
19:07 * meetingology ddstreet to handle "Making it easier for applicants to request special meeting times and/or applying by email"  (carried over)
19:07 <sil2100> Guess we could rename the item, but it's too late now! ;)
19:07 <ddstreet> i believe myself, rbasak, and rafaeldtinoco have provided opinion to either my email or the original one (linked to in my email)
19:07 <ddstreet> so yeah if you (and anyone else interested) can review and respond would be great
19:08 <rafaeldtinoco> I did, I'm +1 of having votes by email by default
19:08 <rafaeldtinoco> and having the meeting if specifically requested
19:08 <sil2100> 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 <sil2100> Ok, I'll throw my 5 cents there then as well
19:09 <sil2100> #topic Ubuntu Core Developer Applications
19:09 <sil2100> #subtopic William Wilson for core-dev (jawn-smith)
19:09 <jawn-smith> o/
19:09 <sil2100> #link https://wiki.ubuntu.com/jawn-smith/CoreDeveloperApplication
19:10 <sil2100> 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 <jawn-smith> Absolutely!
19:11 <jawn-smith> 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 <jawn-smith> Since my last application I have taken some actions to improve my ability to contribute to Ubuntu as a core-dev.
19:12 <jawn-smith> 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 <rafaeldtinoco> and you got 2 recent shifts in +1 maintenance (good)
19:13 <jawn-smith> 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 <jawn-smith> I've also been reading documentation and have finished the Go 1.17 transition.
19:14 <rbasak> o/
19:14 <rbasak> 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 <sil2100> Okay, questions?
19:15 <rafaeldtinoco> rbasak: thank you, very helpful
19:15 <rbasak> 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 <rbasak> So jawn-smith, I wonder if you'd like to elaborate/amend your previous answers for me, please?
19:16 <rbasak> Let's start with transitions. How would you identify that a transition might be triggered before an upload?
19:16 <jawn-smith> Sure thing!
19:17 <jawn-smith> 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 <jawn-smith> 1) if the new package upload changes an ABI without change in API
19:19 <jawn-smith> 2) if the new package upload includes a change of ABI and API
19:19 <jawn-smith> 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 <rbasak> 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 <rbasak> (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 <jawn-smith> 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 <jawn-smith> In addition, and probably the most obvious thing to check is that the names of libraries have changed
19:24 <rbasak> 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 <rbasak> "names of libraries have changed" is close. Can you be more specific?
19:25 <jawn-smith> 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 <rbasak> You're thinking along the right lines.
19:26 <jawn-smith> Seeing that those packages had changed would imply that the shared libraries had changed as well
19:27 <rbasak> 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 <jawn-smith> which would indicate that a transition would be likely
19:30 <jawn-smith> Trying to make sure I understand the question correctly
19:32 <jawn-smith> in this case, libfoo-dev doesn't change version numbers, but can I assume that src:foo also produces binary packages?
19:33 <rbasak> Right
19:35 <jawn-smith> 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 <jawn-smith> s/libopenssl3/libssl3
19:35 <rafaeldtinoco> jawn-smith: are you aware on how code relocation works and symbols versioning ?
19:36 <rafaeldtinoco> what can you tell on top of what rbasak is asking, with that in mind.
19:36 <jawn-smith> So assuming src:foo previously built libfoo1, if it suddently built libfoo1.1 I would know that a transition would be triggered
19:38 <sil2100> 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 <rbasak> 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 <jawn-smith> 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 <rafaeldtinoco> great, feel free to move to sil2100's question please
19:41 <jawn-smith> 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 <jawn-smith> I then created another PPA that had a dependency on my golang-defaults 1.17 PPA
19:42 <jawn-smith> I used the ubuntu-archive-tools to copy every package that appeared in `reverse-depends -b src:golang-defaults`
19:43 <jawn-smith> Thereby rebuilding all of the golang packages against Go 1.17.
19:43 <jawn-smith> 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 <jawn-smith> I determined that the number of new failures was very small and only affected universe packages, and nothing critical.
19:45 <jawn-smith> 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 <sil2100> jawn-smith: ok, thanks o/
19:45 <jawn-smith> I believe rbasak had some more questions :)
19:45 <rbasak> 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 <jawn-smith> The Ubuntu technical board
19:46 <jawn-smith> https://wiki.ubuntu.com/TechnicalBoard
19:46 <rbasak> Great :)
19:46 <sil2100> ;)
19:47 <rbasak> 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 <jawn-smith> Because seeds expand recursively to include their dependencies
19:47 <jawn-smith> meaning that some other package in the desktop seed would depend on libx11-6
19:48 <jawn-smith> maybe not directly, but there would be a chain of dependencies from a package in the desktop seed to libx11-6
19:49 <rbasak> 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 <jawn-smith> I would use the command line tool `seeded-in-ubuntu`
19:49 <rbasak> Great!
19:50 <rbasak> Thank you for your patience! I have no further questions.
19:50 <sil2100> Any other questions?
19:50 <rafaeldtinoco> nope
19:50 <sil2100> ddstreet: ?
19:50 <ddstreet> no q
19:51 <sil2100> #vote Grant William 'jawn-smith' Wilson ubuntu-core-developer
19:51 <meetingology> Please vote on: Grant William 'jawn-smith' Wilson ubuntu-core-developer
19:51 <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')
19:51 <ddstreet> +1 already voted on mailing list
19:51 <meetingology> +1 already voted on mailing list received from ddstreet
19:51 <rbasak> +1 thank you for reapplying!
19:51 <meetingology> +1 thank you for reapplying! received from rbasak
19:51 <sil2100> +1
19:51 <meetingology> +1 received from sil2100
19:52 <rafaeldtinoco> +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 <meetingology> +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 <rbasak> 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 <sil2100> 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 <sil2100> #endvote
19:53 <meetingology> Voting ended on: Grant William 'jawn-smith' Wilson ubuntu-core-developer
19:53 <meetingology> Votes for: 4, Votes against: 0, Abstentions: 0
19:53 <meetingology> Motion carried
19:53 <sil2100> jawn-smith: congratulations!
19:53 <rafaeldtinoco> jawn-smith: welcome to the team
19:53 <rbasak> Congratulations!
19:53 <jawn-smith> woohoo! Thank you everyone!
19:54 <ddstreet> congrats!
19:54 <sil2100> 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 <sil2100> ;)
19:54 <rafaeldtinoco> =)
19:54 <jawn-smith> I sure am!
19:54 <sil2100> #action sil2100 to add jawn-smith to core-dev
19:54 * meetingology sil2100 to add jawn-smith to core-dev
19:54 <sil2100> #action sil2100 to announce jawn-smith's successful application
19:54 * meetingology sil2100 to announce jawn-smith's successful application
19:55 <sil2100> #topic Outstanding mailing list requests to assign
19:55 <rafaeldtinoco> wasn't there another application ?
19:55 <jawn-smith> I think that's for a future meeting
19:55 <sil2100> rafaeldtinoco: no, I think Paride is set for the next meeting
19:55 <rafaeldtinoco> ah ok, my bad
19:55 <rafaeldtinoco> (damn, I read all his application as well, ready for the next one I guess)
19:55 <rafaeldtinoco> =o)
19:56 <sil2100> 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 <ddstreet> in the agenda wiki page, the quorum rule ML item is done
19:57 <ddstreet> but i'd like to ask for a vote on the DMB meeting day/time change, at least 'part 1' of it?
19:57 <sil2100> ACK, and about the new meeting time, are we still waiting on some DMB members to state their availability?
19:57 <sil2100> Ah, we didn't vote yet?
19:57 <ddstreet> 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 <sil2100> Ok, let's vote in that case
19:58 <sil2100> #vote Vote to change the existing 15:00 UTC meetings to 16:00 UTC (leaving the other, alterating ones as they are)
19:58 <meetingology> 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 <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')
19:58 <rbasak> One question - have we identified who that will actually benefit?
19:58 <sil2100> +1
19:58 <meetingology> +1 received from sil2100
19:58 <ddstreet> +1
19:58 <meetingology> +1 received from ddstreet
19:59 <rbasak> IOW, are there members who prefer this change and expect to be able to make more meetings?
19:59 <ddstreet> rbasak i know rafaeldtinoco should benefit from the adjustment, at least
19:59 <rafaeldtinoco> +1
19:59 <meetingology> +1 received from rafaeldtinoco
19:59 <ddstreet> all the specific details of who wants what times are in the ML thread
20:00 <rbasak> 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 <rafaeldtinoco> rbasak: yes, with this change Ill be able to join 2x more meetings (likely)
20:00 <rbasak> Great! In that case...
20:00 <rbasak> +1
20:00 <meetingology> +1 received from rbasak
20:00 <rafaeldtinoco> thanks rbasak !
20:00 <sil2100> #endvote
20:00 <meetingology> 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 <meetingology> Votes for: 4, Votes against: 0, Abstentions: 0
20:00 <meetingology> Motion carried
20:00 <rbasak> And thanks again to ddstreet for organising rescheduling.
20:00 <ddstreet> sure, np
20:00 <rafaeldtinoco> +1 on ddstreet organizing the discussion
20:00 <sil2100> ;)
20:01 <ddstreet> 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 <sil2100> Ok, is this enough votes for us to change the schedule in that case? I suppose I can change the agenda then
20:01 <rbasak> Yes 4 is enough.
20:01 <rbasak> (it's an absolute majority)
20:01 <sil2100> #action ddstreet to follow up on if we should change the 19:00 UTC meetings as well
20:01 * meetingology ddstreet to follow up on if we should change the 19:00 UTC meetings as well
20:01 <sil2100> #topic AOB
20:01 <sil2100> Ok, since we're past our time, any other business?
20:02 <ddstreet> sil2100 do you want to add an action for yourself to adjust the agenda mtg times?
20:02 <ddstreet> on the agenda page i mean
20:02 <sil2100> I wanted to just do this straight after the meeting
20:02 <sil2100> But maybe an action item won't hurt
20:02 <ddstreet> ack good enough
20:02 <ddstreet> either way :)
20:02 <sil2100> ...just in case I get abducted right after the meeting
20:02 <sil2100> #action sil2100 to change the 15:00 UTC meeting times to 16:00 UTC (on Agenda and calendar)
20:02 * meetingology sil2100 to change the 15:00 UTC meeting times to 16:00 UTC (on Agenda and calendar)
20:03 <sil2100> Going once...
20:03 <sil2100> Going twice...
20:03 <sil2100> #endmeeting