=== cpaelzer_ is now known as cpaelzer [16:00] o/ [16:00] o/ [16:00] o/ [16:00] o/ [16:00] * ddstreet gets coffee before others show up [16:00] o/ [16:01] \o [16:02] I suppose we'd love to have at least one more member today, right [16:04] o/ [16:05] I'm finishing lunch following on the cell and rushing to the office in 5 min [16:05] Who can chair today? [16:06] I'm in a concurrent meeting, sorry [16:06] i'd be here if the log4j crap didnt have me neck deep in phone calls and vuln scanning at FT job [16:06] so i am not *really* here right now [16:06] we're down the charing list to sil2100 then, if you are able? [16:07] if not, then it's me [16:09] i'll take the extended silence as an indication i should chair? [16:10] I think I chaired last time? [16:10] At least that's what I remember [16:10] ah ok you might not have moved yourself to the end of the chairing list [16:10] i can chair, it's no prob [16:10] Thanks! [16:11] (I'm also in a backlog review meeting for Foundations, so I'm a bit distracted) [16:11] #startmeeting Developer Membership Board [16:11] Meeting started at 16:11:18 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology [16:11] Available commands: action, commands, idea, info, link, nick [16:11] #topic Review of previous action items [16:12] i think some of the action items got mixed into the 'long-term' action item list? [16:12] i'm going to skip over the ones that i think are long-term items [16:12] #topic sil2100 to add jawn-smith to core-dev (done) [16:12] \o/ [16:12] looks done, thanks :) [16:12] #topic sil2100 to announce jawn-smith's successful application (done) [16:12] also done, thanks [16:13] #topic ddstreet to follow up on if we should change the 19:00 UTC meetings as well [16:13] \o/ [16:13] 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] +1 [16:13] #topic sil2100 to change the 15:00 UTC meeting times to 16:00 UTC (on Agenda and calendar) [16:13] i think this is done right? [16:13] i mean, we're having this mtg at 16:00 UTC, so... ;-) [16:14] the fridge calendar looks out of date [16:14] i think sil2100 just recently changed that? [16:14] like an hour-ish ago? [16:14] I mean, the time of the day is still 15:00 UTZ [16:14] UTC [16:14] oh! [16:14] yes I can confirm it's 16:00 [16:14] ok good, thanks [16:15] Apologies! hm, maybe the fridge one didn't get synced? I don't really remember how the fridge thing works [16:15] Anyway, yeah, I only did the change some hour or two ago after ddstreet reminded me of that [16:15] #topic ddstreet to handle "Making it easier for applicants to request special meeting times and/or applying by email" (carried over) [16:16] 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] ok let's move on to applications then [16:18] we have 2 applications today, in order of the list on the DMB agenda, the PPU application from Athos Ribeiro is first [16:18] #topic PPU application by athos-ribeiro [16:19] hello athos, can you introduce yourself? [16:19] #link https://wiki.ubuntu.com/AthosRibeiro/UbuntuServerDeveloperApplication [16:19] 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] athos you still around? [16:20] 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] 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] and let's open it up for any questions the DMB members have [16:23] yes, that is correct [16:23] thanks! === cpaelzer_ is now known as cpaelzer [16:25] I suspect other members are still reading your application page so let's give things a bit more time [16:25] Yeah, sorry, I didn't have time to do that earlier and now I'm distracted [16:25] But browsing through it now [16:25] ddstreet: I have already read his application for the past meeting and Im good to vote (as I provided an endorsement already). [16:26] athos: tell me, what are the requirements for a change to be considered for an SRU? [16:28] We need to file the SRU paperwork in the LP bug that the change is going to fix [16:28] The impact of the change must be well assessed [16:29] and in general, it should only apply for high impact bugs [16:30] oh, and the bug must be fixed in the development release [16:31] Ok, thanks, sounds good [16:33] 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] and further q from anyone? [16:34] I still might have one, one moment [16:35] 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] 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] athos: are you sure? Are all the arches good to go..? [16:38] * athos chacks [16:38] * athos checks [16:39] the focal package ftbfs in ppc [16:40] Does this mean the package can be released right now? [16:41] 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] the hirsute SRU is good to og though [16:42] Final question: can you imagine any situations when an SRU can be released even in such situation? [16:43] meaning we have a build failure for one specific arch? [16:45] Yes [16:45] * ddstreet coffee refill, back asap [16:46] I suppose it could be released in case that package was never released to that specific platform before [16:49] * ddstreet back [16:50] sil2100 i have one q if you're done? [16:51] 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] that's poorly worded...basically, where does a devel and/or sru patch need to come from? [16:53] It would be nice if a patch comes from the upstream project; however, it may not make much sense sometimes. For instance [16:53] 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] 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] In any case, it is always nice to forward the patch upstream and to debian, to reduce/minimize our deltas. [16:55] 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] is the Origin: listed there the 'best' reference for where the patch came from? [16:58] I see how this could be enhanced to point to a VCS [16:58] what's the downside of using the ML reference instead of the VCS url? [17:00] 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] 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] Commit 6d8380c in OpenVPN/openvpn "Increase listen() backlog queue to 32" [17:01] 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] anyone else have more q? rbasak sil2100 rafaeldtinoco teward? [17:02] no [17:02] No questions here! [17:02] None from me thanks (see abstaining comment above) [17:03] (sorry, was busy with other meetings, eh) [17:03] #vote Packageset application for 'ubuntu-server' packageset for Athos Ribeiro [17:03] Please vote on: Packageset application for 'ubuntu-server' packageset for Athos Ribeiro [17:03] 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] +1 happy with technical work, good endorsements, and good understanding of process, certainly as far as ubuntu-server packages [17:04] +1 happy with technical work, good endorsements, and good understanding of process, certainly as far as ubuntu-server packages received from ddstreet [17:04] you could probably apply for coredev pretty soon, as well [17:05] +1 for ubuntu-server, will get him good experience for core-dev application [17:05] +1 for ubuntu-server, will get him good experience for core-dev application received from rafaeldtinoco [17:05] +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] +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] Just remember about checking ALL the arches for SRUs next time... ;) [17:06] (but also, don't worry too much - there's a lot of core-devs that forget as well!) [17:07] teward i think we're just waiting on your vote? since rbasak is abstaining [17:07] if you're still around [17:08] rbasak do you want to provide your vote, as it looks like teward had to leave? [17:09] If we can't make an absolute majority even with my vote, then I think I need to abstain for now, sorry. [17:09] ack, let's give teward just another couple minutes then, since we're already over time === genii-core is now known as genii [17:11] ok let's call it then [17:11] #endvote [17:11] Voting ended on: Packageset application for 'ubuntu-server' packageset for Athos Ribeiro [17:12] Votes for: 3, Votes against: 0, Abstentions: 0 [17:12] Motion carried [17:12] so technically, it did not pass, as we were short on votes [17:12] Oh, wait [17:12] There were 3 +1s? [17:12] yes [17:12] Sorry I miscounted [17:12] lol [17:13] you want to +1 so we can close it out now? [17:13] 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] excellent, in that case the motion passes, congrats athos! [17:13] as we're over time, i'll take the action to make the changes and announce the results [17:13] unless anyone else wants to quickly volunteer [17:14] #action ddstreet change permissions for athos packageset application for ubuntu-server [17:14] ACTION: ddstreet change permissions for athos packageset application for ubuntu-server [17:14] #action ddstreet announce athos successful application for ubuntu-sever packageset [17:14] ACTION: ddstreet announce athos successful application for ubuntu-sever packageset [17:15] ok, so unfortunately we're now well over time, and we still have paride to consider for coredev [17:15] :) [17:15] rbasak sil2100 rafaeldtinoco paride are *all* of you able to continue? [17:15] I am [17:16] I won't be here for long enough I don't think, unfortunately. [17:16] I can continue if others can [17:16] However, since I'll be abstaining again, you don't really need me. [17:16] (as an exception to normal) [17:17] 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] the alternative is just to reschedule the application to the next meeting [17:17] lets reschedule the meeting then [17:17] 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] paride if you're ok with that let's do it today? [17:18] ddstreet, I am ok with that [17:18] alright [17:18] ok let's do it then :) [17:18] #topic Paride Legovini application for Ubuntu Core Developer [17:18] paride can you introduce yourself? [17:18] #link https://wiki.ubuntu.com/ParideLegovini/UbuntuCoreDeveloperApplication [17:18] sure [17:19] I'm Paride Legovini, in the ubuntu-server (and canonical-server) team since 2019. [17:19] 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] 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] thanks! rafaeldtinoco sil2100, any q? [17:22] 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] 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] first for this MR https://code.launchpad.net/~paride/ubuntu/+source/pmdk/+git/pmdk/+merge/407910 [17:25] what's one thing that might make life significantly harder for the next person that looks at your changes? [17:26] ddstreet, well that patch is build by several commits squashed together [17:26] and that's the reason why there's no direct commit reference in the Origin: DEP3 header [17:27] that's a reason for that: [17:27] the commits fixing that bugs (and related) tests touched the same files in some occasions [17:28] and quilt doesn't like different hunks in a single patch file to touch the same file [17:28] I could have made different patches, one per commit, maybe numerated [17:28] how does using a single patch file improve maintainability over using separate patch files? [17:29] 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] 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] ok so does using a single patch file make maintenance significantly worse? [17:30] (no questions from me if anything) [17:32] 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] ok but also it doesn't make it any better? [17:33] 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] if I don't expect to drop all of them at the same time [17:34] drop all of them? [17:35] i dont follow what you mean? [17:35] sorry. Let's say there is a new upstream release, and a related new merge from Debian [17:36] hmm ... well but you were speaking specifically about SRUs [17:36] let's talk generally then [17:36] 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] 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] 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] that probably will make it past sru review, but trust me, it makes the life of future maintainers much harder [17:40] 1 quilt patch per upstream commit...PLEASE [17:40] ddstreet, I doubt I'll forget this now! :) [17:40] lol [17:41] 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] just a suggestion that makes things much easier for me, that's not required [17:41] ok just one more q, and i know we're WAY over time now [17:42] in the SRU template, what does the 'Regression Potential' or 'Where Problems Could Occur' section mean? what needs to go in there? [17:44] ddstreet, there we should assess what would happen is the proposed change is itself wrong or broken [17:44] it basically challenges the assumptions that justify the SRUability of the fix [17:45] which is normally expected not to have regression. That section deals with the unexpected consequences of the SRU. [17:45] so for example, in this bug https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1906970 [17:45] Launchpad bug 1906970 in postfix (Debian) "[SRU] dpkg hook hostname error" [Unknown, New] [17:45] would you change anything about the answer there? [17:46] I'd remove the generic "very low" bit [17:46] ok thanks [17:47] 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] ok let's move to voting then, and sorry for delaying the vote even longer [17:48] #vote Paride Legovini application for Ubuntu Core Developer [17:48] Please vote on: Paride Legovini application for Ubuntu Core Developer [17:48] 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] +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] +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] +1 [17:50] +1 received from sil2100 [17:50] rafaeldtinoco still around? [17:50] yep [17:50] +1 strong yes based in my experience working together [17:50] +1 strong yes based in my experience working together received from rafaeldtinoco [17:51] rbasak it's three +1, if you're still around for a fourth? [17:51] (im not @ canonical any more so I can say that =) [17:51] thanks Rafael :-) [17:52] 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] 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] #endvote [17:53] Voting ended on: Paride Legovini application for Ubuntu Core Developer [17:53] Votes for: 3, Votes against: 0, Abstentions: 0 [17:53] Motion carried [17:53] thanks to you all for staying so long! [17:53] again not yet carried, but i expect it will pass in the next day or so once we get one more +1 [17:54] sorry for taking so long! [17:54] #action carry vote for paride to ML list for final +1 [17:54] ACTION: carry vote for paride to ML list for final +1 [17:54] #undo [17:54] Removing item from minutes: ACTION [17:54] paride: "almost" welcome =) I hope you get another +1 [17:54] #action ddstreet carry vote for paride to ML list for final +1 [17:54] ACTION: ddstreet carry vote for paride to ML list for final +1 [17:54] rafaeldtinoco, thanks! :) [17:54] ddstreet: thanks for chairing AND for managing this action [17:54] i am sure you will paride so, pre-emptive congratulations :) [17:55] \o/ [17:55] ok let's move on i think we are almost done [17:55] #topic change to DMB meeting day/time (ddstreet) [17:55] this is done; i also started ML discussion around changing the 19:00 UTC mtgs [17:55] #topic next chair [17:56] geez who knows on this...not sure if the chairing list really is useful anymore, at least currently [17:56] #topic AOB [17:56] hahah [17:56] #topic officially cancel Dec 27 meeting? [17:56] YES [17:57] ill be drinking margheritas :P [17:57] on the beach with kids [17:57] rafaeldtinoco damn you, southern-hemisphere! it's cold here! ;-) [17:57] =o) [17:57] ok so i think that mtg is *officially* canceled. [17:58] i'd say its safe to consider that [17:58] #action ddstreet add note in agenda that the dec 27 mtg officially canceled [17:58] ACTION: ddstreet add note in agenda that the dec 27 mtg officially canceled [17:59] 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] but none of our 'normally attending' members need to show up [17:59] nothing else from me, anything else before we close? [17:59] #endmeeting [17:59] Meeting ended at 17:59:55 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-12-13-16.11.moin.txt [17:59] thanks all! o/ [18:00] wow 2 hours [18:03] ddstreet: thanks for chairing the longest meeting from DMB [18:04] rafaeldtinoco lol i get paid double for that meeting, right? xD [18:04] yep, in debcoins [18:05] oh sweet, i'm gonna be a debcoins millionaire...where is that debcoin ATM? ;-) [18:07] athos btw, i've already added you to ~ubuntu-server-dev so you should have upload rights now :) [18:49] ddstreet: yeah i'm a bit insanely busy :P [18:49] log2j has us in a tizzy at FT job