[12:37] slyon: didrocks: thanks for your rust feedback - I guess tomorrow we will sign off the general cleanup of Lucas, then I'll use the same approach to discuss these changes I proposed for rust including the amendment for your feedback [12:40] ack [12:42] . [14:50] o/ [14:54] /o [14:58] looks like rafaeldtinoco is up for chairing, if he's around [14:58] o/ [14:59] sorry, on a track in plumbers, wont be able to participate today (all week == plumbers) [14:59] ack, ok, have fun at plumbers! o/ [14:59] ddstreet: o/ [15:00] i think slashd is around, but we still need 1 more [15:00] sil2100 unfortunately isn't in the channel [15:00] rbasak you around? [15:00] o/ [15:00] I believe sil2100 is unavailable all week [15:00] hurray! [15:00] o/ [15:00] o/ [15:01] unless anyone else wants to volunteer i can chair [15:01] ok we got quite a lot this mtg so let's get it started [15:01] #startmeeting Developer Membership Board [15:01] Meeting started at 15:01:41 UTC. The chair is ddstreet. Information about MeetBot at https://wiki.ubuntu.com/meetingology [15:01] Available commands: action, commands, idea, info, link, nick [15:02] #topic Review of previous action items [15:02] ddstreet edubuntu seed <-> pkgset (carried over) [15:02] nope...i'm moving this one into the 'long-term' section [15:02] #action ddstreet move 'edubuntu seed/pkgset review' into long-term items section [15:02] ACTION: ddstreet move 'edubuntu seed/pkgset review' into long-term items section [15:03] #subtopic rafaeldtinoco look at https://lists.ubuntu.com/archives/devel-permissions/2021-March/001635.html (carried over) [15:03] i'll carry this over, pretty sure he is busy [15:03] #action rafaeldtinoco look at https://lists.ubuntu.com/archives/devel-permissions/2021-March/001635.html (carried over) [15:03] ACTION: rafaeldtinoco look at https://lists.ubuntu.com/archives/devel-permissions/2021-March/001635.html (carried over) [15:04] ok that's all the previous action items, and we have 2 applications today, plus proposals [15:04] i suspect we might not get to the proposals today, so let's do the applications first and see how long that takes [15:05] halves jawn-smith i'm not sure which to start with, you both have been deferred due to lack of quorum before, either of you have preference for going first? [15:05] halves had their application on the agenda first [15:05] So I'm happy to let them go first [15:05] thanks! [15:06] ok so we'll start with halves [15:06] thanks, jawn-smith :) [15:06] np! [15:06] #topic SRU Developer Applications [15:06] #subtopic Heitor Alves de Siqueira [15:06] halves welcome back, can you (re)introduce yourself? [15:07] Here are the logs from the last meeting on this application: https://irclogs.ubuntu.com/2021/08/23/%23ubuntu-meeting.html#t15:38 [15:07] #link https://wiki.ubuntu.com/halves/sru-developer [15:07] thanks and let me link that [15:07] ddstreet sure! [15:07] #link https://irclogs.ubuntu.com/2021/08/23/%23ubuntu-meeting.html#t15:38 [15:07] Hello, everyone! I'm Heitor, and I'd like to (re)-apply for the SRU-developer role. My application page has examples of my work so far: https://wiki.ubuntu.com/halves/sru-developer [15:08] halves: o/ have you reviewed my previous comments with a mentor? [15:08] rbasak I have, yes. thank you for raising those last time [15:09] halves: great, thanks! Who was it please, and can that person please confirm that they think you do have my previous concern straight in your mind now? [15:09] rbasak I have discussed things both with ddstreet and slashd, but I think ddstreet would be my "main" sponsor on this topic [15:10] we did have a meeting on the topic, and discussed the various teams that are involved in the process - halves actually proactively had a list of the various teams ready to discuss with us [15:11] i feel he has a good understanding of all teams involved in the process now [15:11] Great. Thanks! [15:11] I have no further questions :) [15:11] teward slashd any q? [15:11] i have no q myself [15:11] sorry i just had a phone call from work. *reads back* [15:12] ddstreet, I have no questions. [15:12] no questions from me, just the recommendation that if you have any questions ever, just ask. [15:12] no questions from me, just the recommendation that if you have any questions ever, just ask halves. [15:12] sounds good, let's move to voting [15:12] many of us developers are willing to assist where we can if you have questions or odd cases [15:12] #vote Grant Heitor Alves de Siqueira SRU Developer [15:12] Please vote on: Grant Heitor Alves de Siqueira SRU Developer [15:12] 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') [15:13] +1 [15:13] +1 received from rbasak [15:13] +1 [15:13] +1 received from teward [15:13] +1 [15:13] +1 received from ddstreet [15:13] slashd i think you may have dropped and missed the last bit, we jsut started voting [15:14] I did dropped and miss last bit, thanks [15:14] we're currently voting on halves for sru developer, we have three +1 so far [15:15] slashd did you need any backscroll repeated, or have any q? === genii-core is now known as genii [15:15] +1 I worked with halves for years, and I have witnessed severals time his willingness to learn, and do things right + I have reviewed/sponsored many good quality SRU of him. [15:15] +1 I worked with halves for years, and I have witnessed severals time his willingness to learn, and do things right + I have reviewed/sponsored many good quality SRU of him. received from slashd [15:15] #endvote [15:15] Voting ended on: Grant Heitor Alves de Siqueira SRU Developer [15:15] Votes for: 4, Votes against: 0, Abstentions: 0 [15:15] Motion carried [15:15] congrats! [15:15] Congrats halves! [15:16] ok sorry to rush the mtg, but we do have a long agenda, so let's move on [15:16] thanks, all! [15:16] #topic Ubuntu Core Developer Applications [15:17] #suptopic William 'jawn-smith' Wilson [15:17] hello and welcome jawn-smith o/ [15:17] hello, and thanks! o/ [15:17] can you introduce yourself? [15:17] #link https://wiki.ubuntu.com/jawn-smith/CoreDeveloperApplication [15:17] Sure, my name is William, and many people know me as 'jawn-smith' [15:17] My core developer application can be found at https://wiki.ubuntu.com/jawn-smith/CoreDeveloperApplication [15:18] I work on the Ubuntu Foundations team. My responsibilities include Raspberry Pi work, RISC-V, go toolchain, and the ubuntu-image tool [15:19] o/ [15:20] I think that's a good summary for an introduction, but I'm happy to answer any questions you have [15:20] yep please feel free to ask questions rbasak and other members [15:20] Your endorsers mention that you haven't done any transitions yet. That's OK, but can you tell me what a transition is please, and very roughly (no major detail) outline what is involved? [15:21] Actually since getting that feedback from my endorsers I have volunteered to lead the transition of golang-defaults from 1.16 to 1.17 as part of the impish release [15:22] I have done baseline rebuilds of all packages that appear in "reverse-depends -b src:golang-defaults" as well as rebuilding them with Go 1.17 in a PPA [15:22] I then identified 19 packages that had new failures introduced by Go 1.17, and fixed about 6 of them during a +1 maintenance shift last week [15:23] I also created a feature freeze exception request for moving golang-defaults to 1.17, which has been approved: https://bugs.launchpad.net/ubuntu/+source/golang-defaults/+bug/1943502 [15:23] Launchpad bug 1943502 in golang-defaults (Ubuntu) "Feature Freeze Exception: Update golang-defaults to 1.17" [Undecided, Confirmed] [15:23] So while this transition is still in progress, I feel that it has allowed me to gain a pretty good understanding of how to work on transitions [15:26] i'm still reading myself, and assume others are still reading, so if anyone else has more q please jump in [15:26] Could you tell me what a transition is please, and very roughly (no major detail) outline what is involved? [15:27] rbasak: was his previous answer insufficient? [15:28] rbasak: would you like me to expand on my previous messages explaining what I did for the Go transition? [15:28] Sorry I didn't think you had tackled my question. [15:28] Could you go more general please? What's a transition in general, in broad terms? [15:29] Sure [15:31] The transitions I have been exposed to on the foundations team are related to upgrading toolchain source packages. They involve doing test rebuilds of all the build dependencies of the toolchains, as well as resolving autopkgtest failures. [15:32] In addition, according to https://wiki.debian.org/RenamingPackages [15:32] A transition would more broadly include using some "dummy" package to point to a new version that has replaced the original package [15:32] Similar to using golang-defaults to point to Go 1.17 [15:35] How would you identify that an upload inadvertenly triggers a transition? [15:35] If I were to put my understanding of transitions into a very brief summary, I would say that it is using "dummy" packages to update dependencies of other packages, and making sure that the impacts of that change are handled [15:36] rbasak: do you mean checking before the upload that a transition wouldn't be triggered? [15:37] Right - let's assume that you're making a point to check that specifically. What would set off alarm bells in the simplest case? [15:38] If the output of "reverse-depends -b" contained a large number of packages, that would set off alarm bells [15:38] OK, and now that you're looking in detail, what would determine if a transition will be triggered by your upload or not? [15:40] If I did see a large number of packages in "reverse-depends -b" I would do some rebuilds of those packages in a PPA. If some of those packages had new failures to build, I would know that a transition would be triggered [15:41] I would also be happy to ask the community in ubuntu-devel, as I know when to ask questions :) [15:41] :) [15:41] I can confirm that! [15:41] It's good that you know to ask for help :) [15:41] I'm not sure you really understand the packaging model here though, at least in how it relates to transitions. [15:42] Let's move on from transitions. [15:42] Have you done any SRUs? I don't see any references on your application page. [15:42] That does seem like an oversight on my application [15:42] I have done plenty of SRU's [15:42] I will dig up some links [15:43] bug 1891952 [15:43] Bug 1891952 in friendly-recovery (Ubuntu Groovy) "systemd-resolved not started when networking enabled" [High, Fix Released] https://launchpad.net/bugs/1891952 [15:43] Thanks! [15:43] bug 1902025 also is good [15:43] Bug 1902025 in update-manager (Ubuntu Groovy) "hwe kernel not scoped under 'Ubuntu Base'" [Medium, Fix Released] https://launchpad.net/bugs/1902025 [15:43] As part of my RISC-V work I SRU'd u-boot and u-boot-menu to focal to enable booting on the Unmatched [15:44] I agree those links demonstrate that you know what SRUs are and how they work :) [15:44] Okay great, would you like more links? [15:44] No more links on SRUs thanks - unless others have questions? [15:45] I have more questions though. [15:45] ask away :) [15:45] Let's say that you want to upload something but another core dev has a technical objection to your approach. How would you seek to resolve this situation? [15:46] (assume you've already talked to them and you respectfully agree that you're at an impasse) [15:47] In that case I would seek input from more core devs. [15:47] If the majority of core devs agreed with the other person's approach, I would be happy to tackle the problem that way [15:48] What if there's no clear consensus? [15:50] At that point I would try to find someone who would be considered a subject matter expert on the topic and defer to their opinion. For example, if this was an issue with a Raspberry Pi upload I would defer to waveform [15:51] OK, that seems reasonable. Do you know of any specific escalation route for decision making in Ubuntu if consensus cannot be reached? [15:53] I suppose it would depend on the package (i.e. an issue with Go I would likely submit an upstream Bug on their GitHub). But if I wasn't sure I would definitely ask for help :) [15:55] o/ i have some q when rbasak is done [15:55] I have just one more question I think, for now at least. [15:55] jawn-smith: can you tell me what a seed is? [15:57] Yes! At a most basic level a seed is a list of packages [15:58] They logically separate out certain packages based on their importance, functionality, etc [15:58] For example, the boot seed contains the packages needed to boot an image [15:58] The desktop seed contains the packages that are needed to run a desktop environment [16:00] Does that sufficiently answer your question? [16:00] So libx11-6 is a package needed to run a desktop environment, but I don't think it appears in the desktop seed. Why not? [16:02] I would guess that it's installed during the desktop installation process, but that might be another question to ask the community [16:03] OK thanks. No more questions. [16:03] ok i have a few q more focused on sru things [16:04] you have some work sru'ing u-boot, e.g. https://launchpad.net/ubuntu/+source/u-boot/2021.01+dfsg-3ubuntu0~20.04.1 [16:04] in that changelog, could you tell me if anyhting is missing? if so, why, and did this follow the 'normal' sru process that most other packages do? [16:05] Let me look at the change log really quickly [16:07] To answer your question about whether this followed the 'normal' SRU process: I would say no [16:07] how, and why, was it different? [16:08] usually when doing an SRU I would want to pull in the absolute minimal change set to fix a big in the stable release [16:08] but with u-boot we did a more wholesale backport of the package [16:09] This was different because this was for hardware enablement. When doing SRU's for hardware enablement it can work a bit differently where total backports are allowed [16:09] how do you know if a total backport is allowed? [16:11] I know that in the case of hardware enablement a total backport is allowed. I believe there are some other scenarios, but I don't recall off the top of my head [16:12] as for the changelog, there may be some bug numbers missing, and I've gotten mixed opinions on whether or not to include the hirsute changelogs when doing a total backport like this [16:13] fun fact, I actually spent a while doing a minimal change SRU of u-boot only to be told to do a total backport :) [16:13] ok thanks. for the sru process, part of that is adding a sru template, can you list the sections of the template and a very brief comment on what someone should put into the section? [16:13] Yes, I have done quite a few of these templates [16:14] Impact: the impact of the bug. This section should justify why the SRU is needed [16:15] Test Case: detailed steps for how to recreate the issue. This will be used for verification [16:15] Regression potential: where things could go horribly wrong. This is used to help other developers in case things do go wrong [16:16] Other info: anything else that is useful that you think people should know [16:16] for lp #1925267 what do you think of the regression potential section [16:16] Launchpad bug 1925267 in u-boot-menu (Ubuntu Focal) "u-boot unmatched dtb does not match kernel dtb" [Undecided, Fix Released] https://launchpad.net/bugs/1925267 [16:17] Ah I see that this bug is filed against both u-boot and u-boot-menu [16:18] And the regression potential really only covers u-boot-menu [16:18] do you think the comment is enough for that section? anything missing from it? [16:18] and may even be misleading to make testers believe that u-boot does not need to be tested [16:18] From the regression potential section? [16:18] yes [16:19] Yes I do think a list of all hardware using u-boot in focal would be great [16:20] for someone looking at the bug without previous context, do you think they would understand the most likely possible regression outcome from reading that section? [16:20] I do not. I think explaining what a regression would look like (failure to boot) would be helpful [16:21] ok thanks. looking at lp: 1922117 now, [16:21] Launchpad bug 1922117 in urfkill (Ubuntu) "URFkill fails to read RFKILL events with latest kernel" [Undecided, Fix Released] https://launchpad.net/bugs/1922117 [16:22] that bug obviously went into the devel release, so didn't include any sru template. do you think a sru is needed for devel bugs - either in general and/or this specific case? [16:22] I'm looking at it now as well [16:24] I do think an SRU template could never hurt [16:24] I see no reason to not include one, even in a devel release [16:24] That seems to be an oversight on my part for not including it [16:24] sure, i was actually thinking more of an actual sru [16:24] in general, and/or in this bug, is a sru needed? [16:24] Right that's what I meant [16:24] not a sru template [16:25] oh I'm sorry, slightly distracted in a meeting [16:25] yes, my apologies for this going over time :( [16:25] sometimes these run long [16:26] In that specific case I don't think an SRU was needed as it was a change in a kernel ABI that was not present in the kernel in the stable release [16:26] it was caused by* a kernal ABI change that is [16:26] even if using the HWE kernel? [16:27] I'd have to check [16:27] ok thanks. just 1 more q from me, sorry again for going so lonmg [16:27] in your sponsorship list https://udd.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=William+%27jawn-smith%27+Wilson&sponsoree_search=name [16:27] i see the large majority is from other members of foundations [16:28] there are a couple non-foundations sponsors, but only a few [16:28] have you worked much with core-devs outside of the foundations team? [16:28] I've worked with a few others, LocutusOfBorg, bryceh, seb [16:29] (sorry for the pings) [16:29] and I worked with ginggs a bit before he was on the team [16:29] do you think they are familiar enough to provide endorsements, like the ones from your foundations team members? [16:29] In addition I've had a lot of non-foundations devs help me with test re-clicks (only after verifying they were needed of course!) [16:30] I do not think I've worked with them enough to ask them for endorsements [16:30] ok thanks. no more q from me. [16:30] rbasak slashd teward sorry for going so long, any q from any of you? [16:30] i hope we didn't lose any of them [16:30] Due to time and good questions already asked, I'm fine to go and vote. [16:31] i'm still here, no questions from me that weren't already asked [16:31] No more questions from me thanks. I'm ready to vote. [16:31] One thing jawn-smith did do was try to use the sponsoring queue but as we all know that queue is rather long. So when things weren't sponsored the Foundations team ended up sponsoring them. [16:31] ok let's vote then [16:32] #vote Grant William 'jawn-smith' Wilson ubuntu-core-developer [16:32] Please vote on: Grant William 'jawn-smith' Wilson ubuntu-core-developer [16:32] 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') [16:32] So I'd keep that in mind when consider who the sponsors were. [16:32] -1 [16:32] Your technical work and strong endorsements look good. But I'm not sure you have yet built up a mental model of how everything fits together. I'd like for you to build a better understanding of how some of these things operate at a general level. Detail is good but not a requirement here - just enough that you know what they are so you can identify them well enough that you will be able to know [16:32] -1 received from rbasak [16:32] when and where to go for help when required. I very much appreciate your answer that you will ask for help when needed, but I was unable to become confident that you will know when that occurs, and where to go. [16:32] For example, I was looking for you to say that: the simplest case of a transition is that when a reverse build depends is rebuilt, it ends up with different binary dependencies; seeds are at the top level, and expanded recursively according to their dependencies, or alternatively I would have been happy to be provided a link to the docs; the Technical Board (as a last resort) is the escalation [16:32] point for core devs on technical disagreements (see the CoC section on "Value decisiveness, clarity and consensus" for more about Ubuntu's principles here). I don't think I require perfect answers to everything, but I don't think you answers in combination meets my "general understanding" bar. [16:32] I have previously written up a description of what I'm looking to see. I hope this is helpful for you to understand what I'm looking for, and how to get there: https://wiki.ubuntu.com/RobieBasak/DMB/CoreDev [16:32] So, please keep up the excellent work, but for now, I think it'd be appropriate for you to continue working with mentors, instead of uploading to the archive unsupervised. I hope I've given you a clear path to getting a +1 from me here. If you need any clarification or have any questions, please ask, and I look forward to seeing you reapply once you have addressed my concerns. [16:35] -1 most of your technical work seems good to me, but I'm concerned about SRU work; in particular I'm worried that most of your experience has been with the devel release, and most SRU work is with "special" packages that don't follow the normal SRU rules. I also am concerned that most of your experience, and all your endorsements, are from fellow team members on the foundations team. I'd like to see more endorsements from non-foundations [16:35] people, and more SRU work, especially difficult SRU work. [16:35] -1 most of your technical work seems good to me, but I'm concerned about SRU work; in particular I'm worried that most of your experience has been with the devel release, and most SRU work is with "special" packages that don't follow the normal SRU rules. I also am concerned that most of your experience, and all your endorsements, are from fellow team members on the foundations team. I'd like to see more endorsements from non-founda [16:37] -1 for the same reasons that have been indicated by Robie and Dan - namely, I'm concerned about SRU work and that most of the experience you've had is in devel, and as such limited SRU and non-devel experience, and the concerns Robie had with the transitions knowledge. I agree with Robie as well you should continue working with mentors and sponsors for now rather than getting unsupervised upload access. [16:37] -1 for the same reasons that have been indicated by Robie and Dan - namely, I'm concerned about SRU work and that most of the experience you've had is in devel, and as such limited SRU and non-devel experience, and the concerns Robie had with the transitions knowledge. I agree with Robie as well you should continue working with mentors and sponsors for now rather than getting unsupervised upload access. received from teward [16:37] -1 not at this time, but I think you have enough rationale provided by rbasak and ddstreet to know on what to work on. [16:37] -1 not at this time, but I think you have enough rationale provided by rbasak and ddstreet to know on what to work on. received from slashd [16:37] #endvote [16:37] Voting ended on: Grant William 'jawn-smith' Wilson ubuntu-core-developer [16:37] Votes for: 0, Votes against: 4, Abstentions: 0 [16:38] Motion denied [16:38] Thank you for the consideration and feedback! [16:38] sorry jawn-smith but I do encourage reapplying in the futute! [16:38] indeed ^ [16:39] ok thanks everyone, there's still proposals from ML discussion, but i think we're well over time and should defer anything more to the next meeting [16:39] unless there are any objections, i'll end the mtg [16:39] no objections here [16:39] Action for https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_an_unsuccessful_application please [16:39] right thank you rbasak [16:39] thanks you all [16:39] i can take that [16:39] Thanks! [16:39] (and for chairing) [16:40] #action ddstreet announce successful and unsuccessful applications [16:40] ACTION: ddstreet announce successful and unsuccessful applications [16:40] thanks all! o/ [16:40] #endmeeting [16:40] Meeting ended at 16:40:24 UTC. Minutes at https://new.ubottu.com/meetingology/logs/ubuntu-meeting/2021/ubuntu-meeting.2021-09-20-15.01.moin.txt === genii is now known as genii-away === genii-away is now known as genii