16:11 <ddstreet> #startmeeting Developer Membership Board
16:11 <meetingology> Meeting started at 16:11:18 UTC.  The chair is ddstreet.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
16:11 <meetingology> Available commands: action, commands, idea, info, link, nick
16:11 <ddstreet> #topic Review of previous action items
16:12 <ddstreet> i think some of the action items got mixed into the 'long-term' action item list?
16:12 <ddstreet> i'm going to skip over the ones that i think are long-term items
16:12 <ddstreet> #topic sil2100 to add jawn-smith to core-dev (done)
16:12 <jawn-smith> \o/
16:12 <ddstreet> looks done, thanks :)
16:12 <ddstreet> #topic sil2100 to announce jawn-smith's successful application (done)
16:12 <ddstreet> also done, thanks
16:13 <ddstreet> #topic ddstreet to follow up on if we should change the 19:00 UTC meetings as well
16:13 <sil2100> \o/
16:13 <ddstreet> i send a ML email to kick off discussion on this, i don't think we need to keep an action item for it
16:13 <sil2100> +1
16:13 <ddstreet> #topic sil2100 to change the 15:00 UTC meeting times to 16:00 UTC (on Agenda and calendar)
16:13 <ddstreet> i think this is done right?
16:13 <ddstreet> i mean, we're having this mtg at 16:00 UTC, so... ;-)
16:14 <paride> the fridge calendar looks out of date
16:14 <ddstreet> i think sil2100 just recently changed that?
16:14 <ddstreet> like an hour-ish ago?
16:14 <paride> I mean, the time of the day is still 15:00 UTZ
16:14 <paride> UTC
16:14 <paride> oh!
16:14 <paride> yes I can confirm it's 16:00
16:14 <ddstreet> ok good, thanks
16:15 <sil2100> Apologies! hm, maybe the fridge one didn't get synced? I don't really remember how the fridge thing works
16:15 <sil2100> Anyway, yeah, I only did the change some hour or two ago after ddstreet reminded me of that
16:15 <ddstreet> #topic ddstreet to handle "Making it easier for applicants to request special meeting times and/or applying by email" (carried over)
16:16 <ddstreet> I started discussion for this on the ML also, i think that's enough, don't think we need to carry an action item for it
16:17 <ddstreet> ok let's move on to applications then
16:18 <ddstreet> we have 2 applications today, in order of the list on the DMB agenda, the PPU application from Athos Ribeiro is first
16:18 <ddstreet> #topic PPU application by athos-ribeiro
16:19 <ddstreet> hello athos, can you introduce yourself?
16:19 <ddstreet> #link https://wiki.ubuntu.com/AthosRibeiro/UbuntuServerDeveloperApplication
16:19 <rbasak> Both Athos and Paride are colleagues of mine on my team in Canonical, so I'm going to abstain as I normally do in these cases, except if there's a unanimous +1 from all others present and my vote is needed to make quorum.
16:20 <ddstreet> athos you still around?
16:20 <athos> Hello everyone! I am Athos, I work for Canonical in the Server team. My primary focus is in the maintainance and production of the OCI images published in both dockerhub and amazon's ECR. Apart from that, I also perform general bug work throughout the team's packages. Today I am applying for upload rights for the server package set
16:22 <ddstreet> just for clarification, the packageset is 'ubuntu-server', correct? For example for jammy https://people.canonical.com/~ubuntu-archive/packagesets/jammy/ubuntu-server
16:23 <ddstreet> and let's open it up for any questions the DMB members have
16:23 <athos> yes, that is correct
16:23 <ddstreet> thanks!
16:25 <ddstreet> I suspect other members are still reading your application page so let's give things a bit more time
16:25 <sil2100> Yeah, sorry, I didn't have time to do that earlier and now I'm distracted
16:25 <sil2100> But browsing through it now
16:25 <rafaeldtinoco> ddstreet: I have already read his application for the past meeting and Im good to vote (as I provided an endorsement already).
16:26 <sil2100> athos: tell me, what are the requirements for a change to be considered for an SRU?
16:28 <athos> We need to file the SRU paperwork in the LP bug that the change is going to fix
16:28 <athos> The impact of the change must be well assessed
16:29 <athos> and in general, it should only apply for high impact bugs
16:30 <athos> oh, and the bug must be fixed in the development release
16:31 <sil2100> Ok, thanks, sounds good
16:33 <sil2100> btw. for anyone that needs this, sponsorship miner url: https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Athos%20Ribeiro&sponsoree_search=name
16:33 <ddstreet> and further q from anyone?
16:34 <sil2100> I still might have one, one moment
16:35 <sil2100> athos: looking at your recent focal php7.4 SRU - do you think it is good to go? Or is there still some problem something that needs attention?
16:37 <athos> sil2100: it LGTM; There was one autopkgtest failure at some point last week, for which I requested a retrigger (it was just a timeout)
16:37 <sil2100> athos: are you sure? Are all the arches good to go..?
16:38 * athos chacks
16:38 * athos checks
16:39 <athos> the focal package ftbfs in ppc
16:40 <sil2100> Does this mean the package can be released right now?
16:41 <athos> It cannot; this needs fixing. I will request a re-build for that so I can verify the logs, to check if any further change will be needed indeed
16:42 <athos> the hirsute SRU is good to og though
16:42 <sil2100> Final question: can you imagine any situations when an SRU can be released even in such situation?
16:43 <athos> meaning we have a build failure for one specific arch?
16:45 <sil2100> Yes
16:45 * ddstreet coffee refill, back asap
16:46 <athos> I suppose it could be released in case that package was never released to that specific platform before
16:49 * ddstreet back
16:50 <ddstreet> sil2100 i have one q if you're done?
16:51 <ddstreet> athos for a patch to either the devel release or stable release, can you explain any restrictions and/or importance on where the patch comes from?
16:51 <ddstreet> that's poorly worded...basically, where does a devel and/or sru patch need to come from?
16:53 <athos> It would be nice if a patch comes from the upstream project; however, it may not make much sense sometimes. For instance
16:53 <athos> I submitted a patch to python-debian recently to add support for zstd, which was set as the default compression format in impish
16:54 <athos> since Debian does not support zstd, we included that patch downstream (and I am working with upstream to add that support there as well)
16:55 <athos> In any case, it is always nice to forward the patch upstream and to debian, to reduce/minimize our deltas.
16:55 <ddstreet> as an example (and i'm nit-picking here, to be clear) in this MR: https://code.launchpad.net/~athos-ribeiro/ubuntu/+source/openvpn/+git/openvpn/+merge/405957
16:56 <ddstreet> is the Origin: listed there the 'best' reference for where the patch came from?
16:58 <athos> I see how this could be enhanced to point to a VCS
16:58 <ddstreet> what's the downside of using the ML reference instead of the VCS url?
17:00 <athos> A patch in a mainling list is no guarantee that it was indeed applied upstream. One would need check the project to verify that is the actual origin of the patch
17:01 <athos> for this case, you can see it is indeed applied: https://github.com/OpenVPN/openvpn/commit/6d8380c78bf77766454b93b49ab2ebf713b0be48; and this should be the actual reference there
17:01 <ubottu> Commit 6d8380c in OpenVPN/openvpn "Increase listen() backlog queue to 32"
17:01 <ddstreet> thanks, yes that's true; please also keep in mind that all patching would should try to make things as easy as possible for the *next* person who has to look at the code; patching packages isn't *only* about fixing bugs, it's also about doing it in a way that's maintainable with the least friction as possible
17:02 <ddstreet> anyone else have more q? rbasak sil2100 rafaeldtinoco teward?
17:02 <rafaeldtinoco> no
17:02 <sil2100> No questions here!
17:02 <rbasak> None from me thanks (see abstaining comment above)
17:03 <sil2100> (sorry, was busy with other meetings, eh)
17:03 <ddstreet> #vote Packageset application for 'ubuntu-server' packageset for Athos Ribeiro
17:03 <meetingology> Please vote on: Packageset application for 'ubuntu-server' packageset for Athos Ribeiro
17:03 <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:04 <ddstreet> +1 happy with technical work, good endorsements, and good understanding of process, certainly as far as ubuntu-server packages
17:04 <meetingology> +1 happy with technical work, good endorsements, and good understanding of process, certainly as far as ubuntu-server packages received from ddstreet
17:04 <ddstreet> you could probably apply for coredev pretty soon, as well
17:05 <rafaeldtinoco> +1 for ubuntu-server, will get him good experience for core-dev application
17:05 <meetingology> +1 for ubuntu-server, will get him good experience for core-dev application received from rafaeldtinoco
17:05 <sil2100> +1 seeing all the positive endorsements and work done so far, I see no big reasons against! I'm sure you'll do the right thing when in doubt
17:05 <meetingology> +1 seeing all the positive endorsements and work done so far, I see no big reasons against! I'm sure you'll do the right thing when in doubt received from sil2100
17:06 <sil2100> Just remember about checking ALL the arches for SRUs next time... ;)
17:06 <sil2100> (but also, don't worry too much - there's a lot of core-devs that forget as well!)
17:07 <ddstreet> teward i think we're just waiting on your vote? since rbasak is abstaining
17:07 <ddstreet> if you're still around
17:08 <ddstreet> rbasak do you want to provide your vote, as it looks like teward had to leave?
17:09 <rbasak> If we can't make an absolute majority even with my vote, then I think I need to abstain for now, sorry.
17:09 <ddstreet> ack, let's give teward just another couple minutes then, since we're already over time
17:11 <ddstreet> ok let's call it then
17:11 <ddstreet> #endvote
17:11 <meetingology> Voting ended on: Packageset application for 'ubuntu-server' packageset for Athos Ribeiro
17:12 <meetingology> Votes for: 3, Votes against: 0, Abstentions: 0
17:12 <meetingology> Motion carried
17:12 <ddstreet> so technically, it did not pass, as we were short on votes
17:12 <rbasak> Oh, wait
17:12 <rbasak> There were 3 +1s?
17:12 <ddstreet> yes
17:12 <rbasak> Sorry I miscounted
17:12 <ddstreet> lol
17:13 <ddstreet> you want to +1 so we can close it out now?
17:13 <rbasak> In that case, +1, as everyone else still present is unanimous, and my vote will make quorum. That fits my regular abstention rule.
17:13 <ddstreet> excellent, in that case the motion passes, congrats athos!
17:13 <ddstreet> as we're over time, i'll take the action to make the changes and announce the results
17:13 <ddstreet> unless anyone else wants to quickly volunteer
17:14 <ddstreet> #action ddstreet change permissions for athos packageset application for ubuntu-server
17:14 * meetingology ddstreet change permissions for athos packageset application for ubuntu-server
17:14 <ddstreet> #action ddstreet announce athos successful application for ubuntu-sever packageset
17:14 * meetingology ddstreet announce athos successful application for ubuntu-sever packageset
17:15 <ddstreet> ok, so unfortunately we're now well over time, and we still have paride to consider for coredev
17:15 <paride> :)
17:15 <ddstreet> rbasak sil2100 rafaeldtinoco paride are *all* of you able to continue?
17:15 <paride> I am
17:16 <rbasak> I won't be here for long enough I don't think, unfortunately.
17:16 <rafaeldtinoco> I can continue if others can
17:16 <rbasak> However, since I'll be abstaining again, you don't really need me.
17:16 <rbasak> (as an exception to normal)
17:17 <ddstreet> paride so i think we won't be able to pass your application today, however we could proceed with questions and voting from at least rafaeldtinoco and myself, and then move the vote to the ML (and/or the next meeting)?
17:17 <ddstreet> the alternative is just to reschedule the application to the next meeting
17:17 <rafaeldtinoco> lets reschedule the meeting then
17:17 <rbasak> So I suggest that you continue without me if you can, and if required and everyone else is unanimous, I can provide my +1 if I can. Otherwise if it goes to email, then I can do the same on the email thread later unless someone else is 0 or -1 within a reasonable amount of time.
17:17 <ddstreet> paride if you're ok with that let's do it today?
17:18 <paride> ddstreet, I am ok with that
17:18 <rafaeldtinoco> alright
17:18 <ddstreet> ok let's do it then :)
17:18 <ddstreet> #topic Paride Legovini application for Ubuntu Core Developer
17:18 <ddstreet> paride can you introduce yourself?
17:18 <ddstreet> #link https://wiki.ubuntu.com/ParideLegovini/UbuntuCoreDeveloperApplication
17:18 <paride> sure
17:19 <paride> I'm Paride Legovini, in the ubuntu-server (and canonical-server) team since 2019.
17:19 <paride> In the team I do QA and maintain the test infra for the server packages and for the projects developed by the team. But I also do packaging/distro work: merges, bug fixes, SRUs.
17:19 <paride> I also maintain the ISO testing infra for Ubuntu Server, and doing ISO testing I also care about and sometimes touch the installer bits. I am also a Debian Developer.
17:20 <ddstreet> thanks! rafaeldtinoco sil2100, any q?
17:22 <rafaeldtinoco> not from me. I have directly worked with paride and I have confidence in his work. I think he even took too long to apply for core dev. Also, judging from his application page, I think he would be an awesome addition to core-dev team (should even have endorsed him but forgot to).
17:24 <ddstreet> paride i have a couple minor q, both relating to sru work (since 99% of my work is in stable releases, that's almost always my focus)
17:24 <ddstreet> first for this MR https://code.launchpad.net/~paride/ubuntu/+source/pmdk/+git/pmdk/+merge/407910
17:25 <ddstreet> what's one thing that might make life significantly harder for the next person that looks at your changes?
17:26 <paride> ddstreet, well that patch is build by several commits squashed together
17:26 <paride> and that's the reason why there's no direct commit reference in the Origin: DEP3 header
17:27 <paride> that's a reason for that:
17:27 <paride> the commits fixing that bugs (and related) tests touched the same files in some occasions
17:28 <paride> and quilt doesn't like different hunks in a single patch file to touch the same file
17:28 <paride> I could have made different patches, one per commit, maybe numerated
17:28 <ddstreet> how does using a single patch file improve maintainability over using separate patch files?
17:29 <paride> well maybe it doesn't *really* improve it, but it has to be made clear that the separate patch files belong to the same "logical change" (bugfix in this case)
17:29 <ddstreet> for context, i'm not on the ~ubuntu-sru team, but my day job is 'sustaining' ubuntu so this is mostly my only change to correct people's bad SRU behavior on things that too often make it through SRU review
17:30 <ddstreet> ok so does using a single patch file make maintenance significantly worse?
17:30 <sil2100> (no questions from me if anything)
17:32 <paride> ddstreet, mmh I may be wrong of course, but I'd say there's no universal answer. I don't think squashing in a single patch files always makes maintenance worse (otherwise I wouldn't have done it)
17:32 <ddstreet> ok but also it doesn't make it any better?
17:33 <ddstreet> to ask it another way, when you would want to use one patch file per upstream commit, instead of squashing them all into a single patch file?
17:34 <paride> if I don't expect to drop all of them at the same time
17:34 <ddstreet> drop all of them?
17:35 <ddstreet> i dont follow what you mean?
17:35 <paride> sorry. Let's say there is a new upstream release, and a related new merge from Debian
17:36 <paride> hmm ... well but you were speaking specifically about SRUs
17:36 <ddstreet> let's talk generally then
17:36 <ddstreet> is it *ever* good to use one quilt patch file per upstream commit, and also, is it *ever* good to squash multiple upstream commits into a single quilt patch?
17:39 <paride> I'd say that if the upstream commits tackle with different aspects of an issue, and are somehow logically independent, it's good to keep them separated
17:39 <ddstreet> i didn't expect this q to really go this long, so just to skip to the end, the answer is no, please don't ever squash multiple commits into a single patch file
17:39 <ddstreet> that probably will make it past sru review, but trust me, it makes the life of future maintainers much harder
17:40 <ddstreet> 1 quilt patch per upstream commit...PLEASE
17:40 <paride> ddstreet, I doubt I'll forget this now! :)
17:40 <ddstreet> lol
17:41 <ddstreet> and re: logical grouping, i personally always name patches with the bug prefix if there's just 1 patch (e.g. lp123456-commit_desc.patch) and use a subdir for multiple patches (e.g. lp1234567/001-first.patch, lp1234567/0002-second.patch, etc)
17:41 <ddstreet> just a suggestion that makes things much easier for me, that's not required
17:41 <ddstreet> ok just one more q, and i know we're WAY over time now
17:42 <ddstreet> in the SRU template, what does the 'Regression Potential' or 'Where Problems Could Occur' section mean? what needs to go in there?
17:44 <paride> ddstreet, there we should assess what would happen is the proposed change is itself wrong or broken
17:44 <paride> it basically challenges the assumptions that justify the SRUability of the fix
17:45 <paride> which is normally expected not to have regression. That section deals with the unexpected consequences of the SRU.
17:45 <ddstreet> so for example, in this bug https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1906970
17:45 <ubottu> Launchpad bug 1906970 in postfix (Debian) "[SRU] dpkg hook hostname error" [Unknown, New]
17:45 <ddstreet> would you change anything about the answer there?
17:46 <paride> I'd remove the generic "very low" bit
17:46 <ddstreet> ok thanks
17:47 <ddstreet> and i apologize for even asking, as it's kind of a trick question as almost *everyone* sometimes gets that section wrong...personally i'd like to see the ~ubuntu-sru team just remove it from the SRU template entirely :-/
17:48 <ddstreet> ok let's move to voting then, and sorry for delaying the vote even longer
17:48 <ddstreet> #vote Paride Legovini application for Ubuntu Core Developer
17:48 <meetingology> Please vote on: Paride Legovini application for Ubuntu Core Developer
17:48 <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:49 <ddstreet> +1 strong yes, very good technical work, good endorsements, strong understanding of process, all my concerns were trivial(ish) nit-picks, certainly ready for coredev
17:49 <meetingology> +1 strong yes, very good technical work, good endorsements, strong understanding of process, all my concerns were trivial(ish) nit-picks, certainly ready for coredev received from ddstreet
17:50 <sil2100> +1
17:50 <meetingology> +1 received from sil2100
17:50 <ddstreet> rafaeldtinoco still around?
17:50 <rafaeldtinoco> yep
17:50 <rafaeldtinoco> +1 strong yes based in my experience working together
17:50 <meetingology> +1 strong yes based in my experience working together received from rafaeldtinoco
17:51 <ddstreet> rbasak it's three +1, if you're still around for a fourth?
17:51 <rafaeldtinoco> (im not @ canonical any more so I can say that =)
17:51 <paride> thanks Rafael :-)
17:52 <ddstreet> ok so i suspect that's all the votes we will get today, which isn't enough to pass now, but i'm fairly sure rbasak will give his +1 by email
17:53 <ddstreet> he did say he would provide a +1 but just for the sake of process, let's get it officially from him in email
17:53 <ddstreet> #endvote
17:53 <meetingology> Voting ended on: Paride Legovini application for Ubuntu Core Developer
17:53 <meetingology> Votes for: 3, Votes against: 0, Abstentions: 0
17:53 <meetingology> Motion carried
17:53 <paride> thanks to you all for staying so long!
17:53 <ddstreet> again not yet carried, but i expect it will pass in the next day or so once we get one more +1
17:54 <ddstreet> sorry for taking so long!
17:54 <ddstreet> #action carry vote for paride to ML list for final +1
17:54 * meetingology carry vote for paride to ML list for final +1
17:54 <ddstreet> #undo
17:54 <meetingology> Removing item from minutes: ACTION
17:54 <rafaeldtinoco> paride: "almost" welcome =) I hope you get another +1
17:54 <ddstreet> #action ddstreet carry vote for paride to ML list for final +1
17:54 * meetingology ddstreet carry vote for paride to ML list for final +1
17:54 <paride> rafaeldtinoco, thanks! :)
17:54 <rafaeldtinoco> ddstreet: thanks for chairing AND for managing this action
17:54 <ddstreet> i am sure you will paride so, pre-emptive congratulations :)
17:55 <paride> \o/
17:55 <ddstreet> ok let's move on i think we are almost done
17:55 <ddstreet> #topic change to DMB meeting day/time (ddstreet)
17:55 <ddstreet> this is done; i also started ML discussion around changing the 19:00 UTC mtgs
17:55 <ddstreet> #topic next chair
17:56 <ddstreet> geez who knows on this...not sure if the chairing list really is useful anymore, at least currently
17:56 <ddstreet> #topic AOB
17:56 <rafaeldtinoco> hahah
17:56 <ddstreet> #topic officially cancel Dec 27 meeting?
17:56 <rafaeldtinoco> YES
17:57 <rafaeldtinoco> ill be drinking margheritas :P
17:57 <rafaeldtinoco> on the beach with kids
17:57 <ddstreet> rafaeldtinoco damn you, southern-hemisphere! it's cold here! ;-)
17:57 <rafaeldtinoco> =o)
17:57 <ddstreet> ok so i think that mtg is *officially* canceled.
17:58 <rafaeldtinoco> i'd say its safe to consider that
17:58 <ddstreet> #action ddstreet add note in agenda that the dec 27 mtg officially canceled
17:58 * meetingology ddstreet add note in agenda that the dec 27 mtg officially canceled
17:59 <ddstreet> i'll also note that i would like to hold just a pro-forma session that day, to run out the 6-meeting absence counter that we previously established...i'd like to start recruiting new members asap in the new year
17:59 <ddstreet> but none of our 'normally attending' members need to show up
17:59 <ddstreet> nothing else from me, anything else before we close?
17:59 <ddstreet> #endmeeting