15:01 <ddstreet> #startmeeting Developer Membership Board
15:01 <meetingology> Meeting started at 15:01:41 UTC.  The chair is ddstreet.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
15:01 <meetingology> Available commands: action, commands, idea, info, link, nick
15:02 <ddstreet> #topic Review of previous action items
15:02 <ddstreet> ddstreet edubuntu seed <-> pkgset (carried over)
15:02 <ddstreet> nope...i'm moving this one into the 'long-term' section
15:02 <ddstreet> #action ddstreet move 'edubuntu seed/pkgset review' into long-term items section
15:02 * meetingology ddstreet move 'edubuntu seed/pkgset review' into long-term items section
15:03 <ddstreet> #subtopic rafaeldtinoco look at https://lists.ubuntu.com/archives/devel-permissions/2021-March/001635.html (carried over)
15:03 <ddstreet> i'll carry this over, pretty sure he is busy
15:03 <ddstreet> #action rafaeldtinoco look at https://lists.ubuntu.com/archives/devel-permissions/2021-March/001635.html (carried over)
15:03 * meetingology rafaeldtinoco look at https://lists.ubuntu.com/archives/devel-permissions/2021-March/001635.html (carried over)
15:04 <ddstreet> ok that's all the previous action items, and we have 2 applications today, plus proposals
15:04 <ddstreet> 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 <ddstreet> 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 <jawn-smith> halves had their application on the agenda first
15:05 <jawn-smith> So I'm happy to let them go first
15:05 <ddstreet> thanks!
15:06 <ddstreet> ok so we'll start with halves
15:06 <halves> thanks, jawn-smith :)
15:06 <jawn-smith> np!
15:06 <ddstreet> #topic SRU Developer Applications
15:06 <ddstreet> #subtopic Heitor Alves de Siqueira
15:06 <ddstreet> halves welcome back, can you (re)introduce yourself?
15:07 <rbasak> 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 <ddstreet> #link https://wiki.ubuntu.com/halves/sru-developer
15:07 <ddstreet> thanks and let me link that
15:07 <halves> ddstreet sure!
15:07 <ddstreet> #link https://irclogs.ubuntu.com/2021/08/23/%23ubuntu-meeting.html#t15:38
15:07 <halves> 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 <rbasak> halves: o/ have you reviewed my previous comments with a mentor?
15:08 <halves> rbasak I have, yes. thank you for raising those last time
15:09 <rbasak> 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 <halves> rbasak I have discussed things both with ddstreet and slashd, but I think ddstreet would be my "main" sponsor on this topic
15:10 <ddstreet> 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 <ddstreet> i feel he has a good understanding of all teams involved in the process now
15:11 <rbasak> Great. Thanks!
15:11 <rbasak> I have no further questions :)
15:11 <ddstreet> teward slashd any q?
15:11 <ddstreet> i have no q myself
15:11 <teward> sorry i just had a phone call from work.  *reads back*
15:12 <slashd> ddstreet, I have no questions.
15:12 <teward> no questions from me, just the recommendation that if you have any questions ever, just ask.
15:12 <teward> no questions from me, just the recommendation that if you have any questions ever, just ask halves.
15:12 <ddstreet> sounds good, let's move to voting
15:12 <teward> many of us developers are willing to assist where we can if you have questions or odd cases
15:12 <ddstreet> #vote Grant Heitor Alves de Siqueira SRU Developer
15:12 <meetingology> Please vote on: Grant Heitor Alves de Siqueira SRU Developer
15:12 <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')
15:13 <rbasak> +1
15:13 <meetingology> +1 received from rbasak
15:13 <teward> +1
15:13 <meetingology> +1 received from teward
15:13 <ddstreet> +1
15:13 <meetingology> +1 received from ddstreet
15:13 <ddstreet> slashd i think you may have dropped and missed the last bit, we jsut started voting
15:14 <slashd> I did dropped and miss last bit, thanks
15:14 <ddstreet> we're currently voting on halves for sru developer, we have three +1 so far
15:15 <ddstreet> slashd did you need any backscroll repeated, or have any q?
15:15 <slashd> +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 <meetingology> +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 <ddstreet> #endvote
15:15 <meetingology> Voting ended on: Grant Heitor Alves de Siqueira SRU Developer
15:15 <meetingology> Votes for: 4, Votes against: 0, Abstentions: 0
15:15 <meetingology> Motion carried
15:15 <ddstreet> congrats!
15:15 <jawn-smith> Congrats halves!
15:16 <ddstreet> ok sorry to rush the mtg, but we do have a long agenda, so let's move on
15:16 <halves> thanks, all!
15:16 <ddstreet> #topic Ubuntu Core Developer Applications
15:17 <ddstreet> #suptopic William 'jawn-smith' Wilson
15:17 <ddstreet> hello and welcome jawn-smith o/
15:17 <jawn-smith> hello, and thanks! o/
15:17 <ddstreet> can you introduce yourself?
15:17 <ddstreet> #link https://wiki.ubuntu.com/jawn-smith/CoreDeveloperApplication
15:17 <jawn-smith> Sure, my name is William, and many people know me as 'jawn-smith'
15:17 <jawn-smith> My core developer application can be found at https://wiki.ubuntu.com/jawn-smith/CoreDeveloperApplication
15:18 <jawn-smith> I work on the Ubuntu Foundations team. My responsibilities include Raspberry Pi work, RISC-V, go toolchain, and the ubuntu-image tool
15:19 <rbasak> o/
15:20 <jawn-smith> I think that's a good summary for an introduction, but I'm happy to answer any questions you have
15:20 <ddstreet> yep please feel free to ask questions rbasak and other members
15:20 <rbasak> 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 <jawn-smith> 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 <jawn-smith> 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 <jawn-smith> 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 <jawn-smith> 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 <ubottu> Launchpad bug 1943502 in golang-defaults (Ubuntu) "Feature Freeze Exception: Update golang-defaults to 1.17" [Undecided, Confirmed]
15:23 <jawn-smith> 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 <ddstreet> i'm still reading myself, and assume others are still reading, so if anyone else has more q please jump in
15:26 <rbasak> Could you tell me what a transition is please, and very roughly (no major detail) outline what is involved?
15:27 <bdmurray> rbasak: was his previous answer insufficient?
15:28 <jawn-smith> rbasak: would you like me to expand on my previous messages explaining what I did for the Go transition?
15:28 <rbasak> Sorry I didn't think you had tackled my question.
15:28 <rbasak> Could you go more general please? What's a transition in general, in broad terms?
15:29 <jawn-smith> Sure
15:31 <jawn-smith> 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 <jawn-smith> In addition, according to https://wiki.debian.org/RenamingPackages
15:32 <jawn-smith> A transition would more broadly include using some "dummy" package to point to a new version that has replaced the original package
15:32 <jawn-smith> Similar to using golang-defaults to point to Go 1.17
15:35 <rbasak> How would you identify that an upload inadvertenly triggers a transition?
15:35 <jawn-smith> 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 <jawn-smith> rbasak: do you mean checking before the upload that a transition wouldn't be triggered?
15:37 <rbasak> 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 <jawn-smith> If the output of "reverse-depends -b" contained a large number of packages, that would set off alarm bells
15:38 <rbasak> 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 <jawn-smith> 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 <jawn-smith> I would also be happy to ask the community in ubuntu-devel, as I know when to ask questions :)
15:41 <rbasak> :)
15:41 <bdmurray> I can confirm that!
15:41 <rbasak> It's good that you know to ask for help :)
15:41 <rbasak> I'm not sure you really understand the packaging model here though, at least in how it relates to transitions.
15:42 <rbasak> Let's move on from transitions.
15:42 <rbasak> Have you done any SRUs? I don't see any references on your application page.
15:42 <jawn-smith> That does seem like an oversight on my application
15:42 <jawn-smith> I have done plenty of SRU's
15:42 <jawn-smith> I will dig up some links
15:43 <bdmurray> bug 1891952
15:43 <ubottu> Bug 1891952 in friendly-recovery (Ubuntu Groovy) "systemd-resolved not started when networking enabled" [High, Fix Released] https://launchpad.net/bugs/1891952
15:43 <rbasak> Thanks!
15:43 <bdmurray> bug 1902025 also is good
15:43 <ubottu> Bug 1902025 in update-manager (Ubuntu Groovy) "hwe kernel not scoped under 'Ubuntu Base'" [Medium, Fix Released] https://launchpad.net/bugs/1902025
15:43 <jawn-smith> 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 <rbasak> I agree those links demonstrate that you know what SRUs are and how they work :)
15:44 <jawn-smith> Okay great, would you like more links?
15:44 <rbasak> No more links on SRUs thanks - unless others have questions?
15:45 <rbasak> I have more questions though.
15:45 <jawn-smith> ask away :)
15:45 <rbasak> 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 <rbasak> (assume you've already talked to them and you respectfully agree that you're at an impasse)
15:47 <jawn-smith> In that case I would seek input from more core devs.
15:47 <jawn-smith> 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 <rbasak> What if there's no clear consensus?
15:50 <jawn-smith> 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 <rbasak> OK, that seems reasonable. Do you know of any specific escalation route for decision making in Ubuntu if consensus cannot be reached?
15:53 <jawn-smith> 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 <ddstreet> o/ i have some q when rbasak is done
15:55 <rbasak> I have just one more question I think, for now at least.
15:55 <rbasak> jawn-smith: can you tell me what a seed is?
15:57 <jawn-smith> Yes! At a most basic level a seed is a list of packages
15:58 <jawn-smith> They logically separate out certain packages based on their importance, functionality, etc
15:58 <jawn-smith> For example, the boot seed contains the packages needed to boot an image
15:58 <jawn-smith> The desktop seed contains the packages that are needed to run a desktop environment
16:00 <jawn-smith> Does that sufficiently answer your question?
16:00 <rbasak> 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 <jawn-smith> I would guess that it's installed during the desktop installation process, but that might be another question to ask the community
16:03 <rbasak> OK thanks. No more questions.
16:03 <ddstreet> ok i have a few q more focused on sru things
16:04 <ddstreet> 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 <ddstreet> 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 <jawn-smith> Let me look at the change log really quickly
16:07 <jawn-smith> To answer your question about whether this followed the 'normal' SRU process: I would say no
16:07 <ddstreet> how, and why, was it different?
16:08 <jawn-smith> 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 <jawn-smith> but with u-boot we did a more wholesale backport of the package
16:09 <jawn-smith> 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 <ddstreet> how do you know if a total backport is allowed?
16:11 <jawn-smith> 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 <jawn-smith> 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 <jawn-smith> 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 <ddstreet> 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 <jawn-smith> Yes, I have done quite a few of these templates
16:14 <jawn-smith> Impact: the impact of the bug. This section should justify why the SRU is needed
16:15 <jawn-smith> Test Case: detailed steps for how to recreate the issue. This will be used for verification
16:15 <jawn-smith> Regression potential: where things could go horribly wrong. This is used to help other developers in case things do go wrong
16:16 <jawn-smith> Other info: anything else that is useful that you think people should know
16:16 <ddstreet> for lp #1925267 what do you think of the regression potential section
16:16 <ubottu> 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 <jawn-smith> Ah I see that this bug is filed against both u-boot and u-boot-menu
16:18 <jawn-smith> And the regression potential really only covers u-boot-menu
16:18 <ddstreet> do you think the comment is enough for that section? anything missing from it?
16:18 <jawn-smith> and may even be misleading to make testers believe that u-boot does not need to be tested
16:18 <jawn-smith> From the regression potential section?
16:18 <ddstreet> yes
16:19 <jawn-smith> Yes I do think a list of all hardware using u-boot in focal would be great
16:20 <ddstreet> 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 <jawn-smith> I do not. I think explaining what a regression would look like (failure to boot) would be helpful
16:21 <ddstreet> ok thanks. looking at lp: 1922117 now,
16:21 <ubottu> 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 <ddstreet> 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 <jawn-smith> I'm looking at it now as well
16:24 <jawn-smith> I do think an SRU template could never hurt
16:24 <jawn-smith> I see no reason to not include one, even in a devel release
16:24 <jawn-smith> That seems to be an oversight on my part for not including it
16:24 <ddstreet> sure, i was actually thinking more of an actual sru
16:24 <ddstreet> in general, and/or in this bug, is a sru needed?
16:24 <jawn-smith> Right that's what I meant
16:24 <ddstreet> not a sru template
16:25 <jawn-smith> oh I'm sorry, slightly distracted in a meeting
16:25 <ddstreet> yes, my apologies for this going over time :(
16:25 <ddstreet> sometimes these run long
16:26 <jawn-smith> 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 <jawn-smith> it was caused by* a kernal ABI change that is
16:26 <ddstreet> even if using the HWE kernel?
16:27 <jawn-smith> I'd have to check
16:27 <ddstreet> ok thanks. just 1 more q from me, sorry again for going so lonmg
16:27 <ddstreet> 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 <ddstreet> i see the large majority is from other members of foundations
16:28 <ddstreet> there are a couple non-foundations sponsors, but only a few
16:28 <ddstreet> have you worked much with core-devs outside of the foundations team?
16:28 <jawn-smith> I've worked with a few others, LocutusOfBorg, bryceh, seb
16:29 <jawn-smith> (sorry for the pings)
16:29 <jawn-smith> and I worked with ginggs a bit before he was on the team
16:29 <ddstreet> do you think they are familiar enough to provide endorsements, like the ones from your foundations team members?
16:29 <jawn-smith> 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 <jawn-smith> I do not think I've worked with them enough to ask them for endorsements
16:30 <ddstreet> ok thanks. no more q from me.
16:30 <ddstreet> rbasak slashd teward sorry for going so long, any q from any of you?
16:30 <ddstreet> i hope we didn't lose any of them
16:30 <slashd> Due to time and good questions already asked, I'm fine to go and vote.
16:31 <teward> i'm still here, no questions from me that weren't already asked
16:31 <rbasak> No more questions from me thanks. I'm ready to vote.
16:31 <bdmurray> 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 <ddstreet> ok let's vote then
16:32 <ddstreet> #vote Grant William 'jawn-smith' Wilson ubuntu-core-developer
16:32 <meetingology> Please vote on: Grant William 'jawn-smith' Wilson ubuntu-core-developer
16:32 <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')
16:32 <bdmurray> So I'd keep that in mind when consider who the sponsors were.
16:32 <rbasak> -1
16:32 <meetingology> -1 received from rbasak
16:32 <rbasak> 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 <rbasak> 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 <rbasak> 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 <rbasak> 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 <rbasak> 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 <rbasak> 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 <ddstreet> -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 <ddstreet> people, and more SRU work, especially difficult SRU work.
16:35 <meetingology> -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 received from ddstreet
16:37 <teward> -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 <meetingology> -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 <slashd> -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 <meetingology> -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 <ddstreet> #endvote
16:37 <meetingology> Voting ended on: Grant William 'jawn-smith' Wilson ubuntu-core-developer
16:37 <meetingology> Votes for: 0, Votes against: 4, Abstentions: 0
16:38 <meetingology> Motion denied
16:38 <jawn-smith> Thank you for the consideration and feedback!
16:38 <ddstreet> sorry jawn-smith but I do encourage reapplying in the futute!
16:38 <slashd> indeed ^
16:39 <ddstreet> 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 <ddstreet> unless there are any objections, i'll end the mtg
16:39 <teward> no objections here
16:39 <rbasak> Action for https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Actions_after_an_unsuccessful_application please
16:39 <ddstreet> right thank you rbasak
16:39 <slashd> thanks you all
16:39 <ddstreet> i can take that
16:39 <rbasak> Thanks!
16:39 <rbasak> (and for chairing)
16:40 <ddstreet> #action ddstreet announce successful and unsuccessful applications
16:40 * meetingology ddstreet announce successful and unsuccessful applications
16:40 <ddstreet> thanks all! o/
16:40 <ddstreet> #endmeeting