=== lan3y is now known as laney === juliank is now known as jak === jak is now known as juliank [14:25] hello [14:29] good morning [14:29] good afternoon/$timeofday [14:30] o/ [14:30] o/ [14:31] #startmeeting Weekly Main Inclusion Requests status [14:31] Meeting started at 14:31:17 UTC. The chair is slyon. Information about MeetBot at https://wiki.ubuntu.com/meetingology [14:31] Available commands: action, commands, idea, info, link, nick [14:31] Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer jamespage [14:31] c_paelzer is on vacation AFAIK [14:31] #topic current component mismatches [14:31] Mission: Identify required actions and spread the load among the teams [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [14:31] #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg [14:32] c-m looking as usual (except for network-manager -> iwd, which is also in c-m-proposed) [14:32] c-m-proposed: [14:32] hey o/ [14:33] I was able to get a few things moving, namely systemd -> systemd-hwe and mutt -> gsasl [14:33] \o/ [14:33] looks like network-manager -> iwd -> ell also resolved the leaf level [14:33] and the lintian dependencies are making some progress \o/ [14:34] I see nothing else noteworthy in there.. [14:35] should we point out to the kernel team that their linux-raspi-unstable appears to be in universe? [14:35] I don't know how their packages are arranged, it probably doesn't really matter one way or another [14:36] oh right that seed change! [14:36] who could we ping about that? [14:38] good question; on the one hand, I think apw is an archive admin and would know how to sort it out quick, but pinging one person in a big team isn't great; maybe just drop it in ~Kernel and see if it falls off the list next week? :) [14:38] sarnold: sounds like a plan! Would you mind doing that? [14:38] sure thing! [14:38] thanks [14:38] #topic New MIRs [14:38] Mission: ensure to assign all incoming reviews for fast processing [14:38] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&assignee_option=none&field.assignee=&field.subscriber=ubuntu-mir [14:39] tuna and tuned [14:39] We have two new cases ^ bug #1988066 [14:39] Bug 1988066 in tuned (Ubuntu Jammy) "[MIR] tuned" [High, New] https://launchpad.net/bugs/1988066 [14:40] it doesn’t seem that it’s following the template, like elements about tests have been removed for instance [14:40] well. actually, it’s modified from the template and written with: [14:40] * No Test Suite shipped with the package [14:41] so could still be reviewed [14:41] (I have been p-uzzled by the Overview section) [14:41] seems like this will be maintained by the kernel team. [14:41] and i dont understand if it's 2 source packages or 1 [14:41] hmm; we have tlp and gamemode in main already [14:42] do we have any volunteers to have a look at that? [14:42] joalif: it's two source packages, src:tuna and src: tuned [14:42] seems to be two according to launchpad [14:42] TBH, not sure I can commit this week. I finished yesterday the 2 on -perl and spent some times on it [14:42] so if it can be only handled next week (after next meeting), I can take one [14:42] I cannot commit to anything this week either, as I'll be out on vacation in 2 days [14:43] joalif: are you interested (and have capacity) to take one of them? I think you still have the other 2 -perl reviews on the list, though [14:43] yes [14:44] I've done the other 2 [14:44] a couple of hours earlier [14:44] joalif: thanks! So feel free to pick one (or both, if you're feeling lucky ;-) ) and assign your name to in on launchpad [14:44] they are on security now [14:44] i'll take one [14:44] joalif: ah perfect, thanks a lot. I didn't see that yet [14:45] @slyon I took tuna [14:45] I’ll probably wait on next week before grabbing it, in case someone beats me to it :) [14:45] #Info joalif to review tuna [14:45] okay. so we'll leave tuned untouched for now, to be assigned next week [14:46] #info tuned to be assigned next week [14:46] #topic Incomplete bugs / questions [14:46] Mission: Identify required actions and spread the load among the teams [14:46] #link https://bugs.launchpad.net/ubuntu/?field.searchtext=&orderby=-date_last_updated&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.subscriber=ubuntu-mir [14:47] bug #1963707 [14:47] Bug 1963707 in libqrtr-glib (Ubuntu) "[MIR] libqrtr-glib" [Low, Incomplete] https://launchpad.net/bugs/1963707 [14:47] seb asked a question about hardware availability... [14:48] didrocks: do you know if we had similar cases in the past? where MIR team is requiring that the hardware is available for testing? [14:48] I think it makes sense to have that requirement, otherwise the manual test plan is useless (unless testing is done by the community..) [14:49] slyon: the hardware/fallback to manual test is quite recent actually (like a year ago?) when we started to make tests a requirement [14:49] but the team committed to do the manual testing, which doesn't work without hardware [14:49] which is a good thing I think, but we don’t have precedence [14:49] most of stuff comes with tests. desktop components don’t often unfortunately :/ [14:49] so yeah, we are quite in a blocking situation here [14:50] I don’t feel it’s good to continue delivering things without testing (automatically or at least manually) [14:50] I agree, we should stick to the testing requirement [14:50] didrocks: +1 not that i have much to say as i don't work at Canonical, but is that modem avalible in cheaper usb devices? [14:50] I guess the fact that he is upset is about the ACK, then NACK [14:50] just a random tough [14:51] yes, that ACK->NACK was a bit unfortunate. [14:52] luna__: didrocks: I'll add a comment, that we want to stick to that requirement [14:52] TBH, if they haven’t told us they didn’t have the hw, we wouldn’t know [14:52] so I think that no proof of automated tests, for all new components, is maybe the wrong path [14:52] (even if it’s a simple test) [14:52] and I don’t feel that every upload will follow the testplan [14:53] so… on that topic [14:53] we should make our QA team entering the discussion [14:53] as in the end, they will be the one owning the testing story [14:53] and they should be the ones deciding if the component is enough testing or not, and how [14:53] +1 [14:53] rather then the MIR team [14:53] oh, do we have a qa team that's staffed enough to do those things? [14:53] unsure about the staffed enough part :p [14:53] but bdmurray is leading it AFAIK? [14:54] something to discuss at next IRL sprint? [14:54] cc bdmurray: ^ (we'd be interested in the QA teams opinion on the "manual testing" story for packages in the main component) [14:54] yes, that might be a good topic for the next IRL sprint [14:57] OK, i added a comment. moving on [14:57] bug #1986591 [14:57] Bug 1986591 in fstrm (Ubuntu) "[MIR] fstrm" [Undecided, Incomplete] https://launchpad.net/bugs/1986591 [14:57] tracking update [14:58] vpnc-scripts: tracking update & seems to be still actively worked on, bug #1987571 [14:58] Bug 1987571 in vpnc-scripts (Ubuntu) "[MIR] vpnc-scripts" [Undecided, Incomplete] https://launchpad.net/bugs/1987571 [14:59] bug #1987447 is still searching for an owning team [14:59] Bug 1987447 in python-mechanize (Ubuntu) "[MIR] python-mechanize" [Undecided, Incomplete] https://launchpad.net/bugs/1987447 [15:00] same story with #1987448 [15:00] bug #1987448 [15:00] Bug 1987448 in stoken (Ubuntu) "[MIR] stoken" [Undecided, Incomplete] https://launchpad.net/bugs/1987448 [15:00] yeah, we should probably something in the MIR template [15:00] same, bug #1987446 [15:00] Bug 1987446 in openconnect (Ubuntu) "[MIR] openconnect" [Undecided, Incomplete] https://launchpad.net/bugs/1987446 [15:00] that first, agree with the owning team that they will own it [15:01] same bug #1987446 [15:01] didrocks: that sounds like a very useful addition. Would you mind creating a PR to update the template accordingly, so it can be discussed next week? [15:01] sigh. I thought I was clear to luis that he needs to find someone to own these packages. [15:02] slyon: will do! [15:02] thanks! [15:02] bug #1980662 (lintian vs *-perl) needs some work on two packages and sec-review on the other two, thanks joalif and didrocks for the reviews! [15:02] Bug 1980662 in lintian (Ubuntu) "[MIR] lib*-perl for lintian 2.115" [Undecided, Confirmed] https://launchpad.net/bugs/1980662 [15:02] nothing to do for us on those. [15:03] #topic MIR related Security Review Queue [15:03] Mission: Check on progress, do deadlines seem doable? [15:03] #link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=%5BMIR%5D&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir [15:03] sarnold: [15:03] the good news is that we worked through far more of our backlog than I thought possible, thanks to the team for pitching in! [15:04] the bad news is that the rest of the team has some very high priority work that cannot be delayed further, so it'll return to just me for a bit, and I'm not yet over covid, so might not be as productive as usual (heh) [15:04] good luck :/ [15:04] mdevctl is in progress, nullboot is a hot potato, and these new lib perl packages don't feel like the usual lintian "oh yeah that's fine" faire :( [15:05] I'll see what I can do to keep making progress ;) but it won't be like the last two weeks, that's for sure [15:06] yes I saw a lot of security review in the last weeks, which is very nice. But I'm aware of (some of) the current "hot" security topics, which of course need to take priority [15:07] #topic Any other business? [15:07] yes [15:07] nothing from me [15:07] ddstreet has found greener pastures; do we need to find someone to replace his inputs? [15:07] not from me [15:07] luna__: thanks for your interest and contribution to the MIR process [15:07] no problem, had some spare time today [15:07] sarnold: joalif was ddstreet's replacement, AFAIK [15:08] slyon: aha! [15:08] * sarnold falls over [15:08] yup [15:08] I've read the backlog and I think the libqrtr-glib requirement is a bit unfortunate. If we don't have the hardware nor budget to buy some it means we can't enable support for our users [15:08] it's lucky that the kernel doesn't go through MIR review with the current rules [15:08] NAK NAK NAK NAK [15:08] we would have lot of hardware support missing in Ubuntu :p [15:08] :D [15:08] "please come back with a more secure kernel kthxbye" [15:09] joke aside, I don't really know how to resolve it at this point, I can ask to expense so laptop for testing but I've an idea how that's going to end up [15:09] seb128: the test plan really could have been "I have a buddy with a laptop who promised to test every single update when we need it", I think [15:10] .. assuming your buddy is that willing? [15:10] I didn't find anyone owning that hardware though [15:10] The kernel is a special case, indeed. but we try to apply the new and improved rules as strictly as possible, at least for any new promotions [15:10] just a few random users who complain about Ubuntu not supporting things that works in fedora [15:10] it's frustrating to not be able to have an answer :/ [15:11] slyon, I think hardware is sort of a special case [15:11] how not supporting the hardware at all is a win for anyone? [15:11] its not [15:11] if we don't do any testing, we might end up with a broken system, which might be worse than a known missing hardware support [15:11] which is also true for the kernel... [15:12] it's an inconsistent policy [15:13] I agree there's an inconsistency and we should bring it up for discussion, maybe during the next engineering sprint [15:13] slyon, I think it's inconsistent also with the initial position we took for Ubuntu [15:13] we always said hardware support was important and we wanted to enable as much hardware as possible, at the extend to allowing binary drivers [15:14] anyway, I made my point, I don't feel like I will have more traction on the topic unless I decide to escalade to the TB? [15:14] * luna__ agress with seb128 [15:14] nvidia is also a problem :( https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1853977 [15:14] Launchpad bug 1853977 in nvidia-graphics-drivers-340 (Ubuntu) "nvidia-340 dpkg: error: version '-' has bad syntax: revision number is empty" [Undecided, Confirmed] [15:14] yes. I can see both sides of this. But I don't feel senior enough to make a call about this right now... [15:14] I'm not asking for a call to be made today [15:15] maybe before escalating it to the TB, we might loop in c_paelzer into the discussion, once he returns from vacation (next week AFAIK) [15:15] k, I will wait for him to be back before raising to TB [15:15] thanks [15:15] thanks! [15:15] the more I think about it, the more I think the QA team should be owner of this testing requirements [15:15] they are the one identifying gaps, and ultimately, being reponsible of the distro [15:16] if we have one, I agree :) [15:16] didrocks, it's easier for software than for hardware where budget is often a blocker as you know :/ [15:16] so we should also loop in bdmurray and paride [15:16] but yes, included QA makes sense [15:16] seb128: oh yeah, I know… remember on pitti’s day and how he tried to mock edge packages? but for that, we need staffing… [15:17] I've also tried to reach to oem but they aren't enabling models with that hardware atm [15:17] maybe we should restrict the hw requirements on certified hw? [15:17] this is another opportunity [15:17] didrocks: seb128 +1 [15:17] and then, it’s up to have a testsuite running in the oem lab [15:18] didrocks, slyon, so the decision is that I should rollback the modemmanager depends to unblock proposed at this point I guess? [15:18] but how do we know which hardware is available in the cert lab? And what if that set of hardware changes? [15:19] Wiki page, Libreoffice Spreadsheet? :D [15:20] seb128: If you want it now, then that's unfortunately the way to go, I guess. If you can wait 1-2 more weeks, we might be able to continue that discussion with more team members and possibly come up with a solution (or exception) [15:20] https://wiki.canonical.com/PES/Infrastructure/TestFlingerDevices ? :) [15:20] sweet! ^ [15:20] granted, it isn't at the granularity of "what modems are on these devices" [15:20] so my Wiki page idea was not all that dumb then [15:20] lspci, lsusb, lshw on everything ;) [15:21] slyon, I think we can wrap that topic for today and try again when Christian isback [15:22] sorry for delaying the end of meeting [15:22] its all fine [15:22] seb128: okay. thanks for your input! [15:22] #endmeeting [15:22] Meeting ended at 15:22:48 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-30-14.31.moin.txt [15:22] thanks slyon, seb128, all :) [15:22] thanks all! [15:22] thanks! [15:22] thx [15:23] thanks! [15:26] thanks all === kees_ is now known as kees [18:59] * vorlon waves [18:59] hey :) Khurshid's joining now [19:00] o/ [19:00] cough looks like I didn't update the agenda wiki page after the last meeting; doing now [19:00] o/ [19:01] (semi-around only) [19:02] (done) [19:02] sil2100: you're in rotation for chairing, are you able to today? [19:02] vorlon: eh, I'm a bit scrambled, could I perhaps skip and try at a calmer time? [19:03] * rs2009 has a question [19:03] well, cyphermox is backup; cyphermox are you here? [19:03] will ubuntu unity's flavor proposal be discussed today? [19:04] (I don't see it on the agenda, hence asking) [19:04] Should be added to the agenda I reckon. [19:05] I can chair I guess. [19:05] #startmeeting Ubuntu Technical Board [19:05] Meeting started at 19:05:05 UTC. The chair is rbasak. Information about MeetBot at https://wiki.ubuntu.com/meetingology [19:05] Available commands: action, commands, idea, info, link, nick [19:05] rs2009: community members are welcome to edit the wiki page to add things to our agenda; but we would normally at least cover this under email follow-up [19:06] sure vorlon, just added it [19:06] Why don't we start with Unity, as rs2009 and saif are here? [19:06] #topic Ubuntu Unity's official flavor proposal [19:07] here's our proposal: https://wiki.ubuntu.com/UbuntuUnity/22.10/Proposal [19:07] I also sent an email regarding this yesterday [19:07] Following the recent thread on the techboard ML, we've been looking into how to make the new flavour process better and clearer. But that's still a work in progress. [19:07] So some of this is still in flux. [19:07] the proposal looks good to me overall, just a few things that I think it's important to lock down vs the policy [19:07] rbasak: right, I'm assuming we should be using the current wiki page for assessing this flavor proposal [19:08] I'm fine with that in principle, but the current wiki page doesn't really define who does what. [19:08] I'm not that familiar with the details, and also IMHO this kind of thing should be delegated to the release team. So I'd like to essentially leave this to you for now. [19:09] I'm also in general +1 on the flavor proposal, and I'm happy to see the progress they made towards this goal [19:09] If you're happy, I'm happy. I figure we just need a list of todos for the Unity team. [19:10] Should we do a formal vote for acknowledging the new flavor in-progress? [19:10] governance-wise I think the TB is who should be signing off on flavors [19:10] but leaning on the release team for specifics is fine [19:10] I agree the TB should have final sign-off. But yes - I'd like to do that only if the release team have examined and that they are happy. [19:10] But +1 in principle, of course. [19:11] rs2009: one thing we need to hear is that seb128 is willing to be officially the uploader for the flavor (as opposed to just an Ubuntu developer who pitches in) [19:13] vorlon: I understand. He's been the MOTU who's been uploading the packages all these years and is already the official uploader of the packages [19:14] in fact, he told me just yesterday that he's in the process of uploading the latest Unity 7.6 packages to kinetic [19:14] rs2009: otherwise, I think the next steps are for you to go through the sections on https://wiki.ubuntu.com/RecognizedFlavors labeled "Guidelines to have an image added to dailies" and "Guidelines to become and remain a recognized flavor" and confirm that you're meeting all these requirements (and document in your proposal how they are met). For Release Team, please coordinate in #ubuntu-release [19:14] on IRC [19:14] and you can consider the IS check-off done, we know have the space right now [19:15] sure, we've gone through the sections and I can confirm that we've already completed all the steps under "Guidelines to become and remain a recognized flavor" [19:15] (we have actually been planning this since two years) [19:15] As a flavour that was once the main face of Ubuntu, with an established infrastructure, Unity should clearly be on the official flavour list. It defined ubuntu and distinguished it from others with a passionate following despite everything that ha [19:16] Etc... [19:17] rs2009: right - can you document this explicitly on the wiki page? E.g. "Leading members have signed Ubuntu Code of Conduct" can you point on the wiki page to who has signed the CoC? [19:17] sure, I'll do it right away. Leading members are me and Khurshid, and we've already signed the CoC [19:18] our QA lead, Maik, is an Ubuntu member and has also signed the CoC [19:18] saif: I appreciate the sentiment, but software stacks change over time, and it is not a foregone conclusion that it be an official flavor because there's a community that liked the UX - we have a process :) [19:18] I think that covers us for next steps on ubuntu-unity then [19:19] rs2009: are you clear on your next steps? Any other questions? [19:19] Please do ask on the mailing list if you get stuck with anything. [19:20] rbasak: yep, I am. thanks :) will the voting happen today? [19:20] I think all steps need to be complete before we make a final decision. [19:20] agreed [19:21] wiki page updated, confirmation from seb128 that he's agreeing to be on the hook [19:21] rs2009: but in general, so far you are on track, so don't worry! [19:21] Hopefully this will just be a formality [19:22] Agreed. I think everyone is happy with this being an official flavour in principle. It's just about the technical arrangements and ensuring that there are enough qualified developers to be able to support it, etc. [19:22] vorlon: I just completed the steps [19:22] I've updated the proposal with all the needed info [19:23] I don't see a statement of commitment _from_ seb128? [19:24] oh, I'll get a statement from him. Will try to do it while this meeting is on [19:24] Sure, thanks. [19:24] I think he's busy in European evenings though. But feel free to try :) [19:24] #topic Action review [19:24] ACTION: (everyone) review the Ubuntu Backports Team Charter for ratification [19:25] This needs carrying over still I think. [19:25] #action (everyone) review the Ubuntu Backports Team Charter for ratification [19:25] ACTION: (everyone) review the Ubuntu Backports Team Charter for ratification [19:25] ACTION: rbasak to finalize third-party seeded snap security policy [19:25] I'll discuss this under its own topic [19:25] ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. [19:25] Blocked on the above [19:25] ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step [19:25] * vorlon nods [19:25] ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:25] This needs carrying over still [19:25] #action rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:25] ACTION: rbasak to draft a proposal of the DMB-proposed inactivity expiration policy for TB ratification [19:26] ACTION: cyphermox to re-ping the CC regarding the TB nominations and election [19:26] cyphermox, sil2100: any updates please? [19:26] CC member here, sorry about that, if I have to run the elections on that, I will. [19:26] My action item is still in the works... [19:26] Most of the CC has been very absent as of late, unfortunately. [19:27] Right now we're one member down, and the remainder's terms expire at the end of this year. [19:28] With the Christmas/New Year shutdown in the way, it might be an idea to try to gather the full set of nominations all at once, but up to you. [19:28] Thanks Eickmeyer :) [19:28] #action sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step [19:28] ACTION: sil2100 to start a draft summarizing the OEM archive portion of the meeting which x-nox and TB will review, edit, and ratify before we move on to figuring out the next step [19:29] I guess we'll carry over cyphermox's action for now then. [19:29] rbasak: I'll see what I can do. We've been pinged by Phil with little response. Only a couple of us have been very active lately, and it's been trying on us to do all of the lifting. [19:29] #action cyphermox to follow up with the CC regarding the TB nominations and election [19:29] ACTION: cyphermox to follow up with the CC regarding the TB nominations and election [19:29] #topic Definition of our third party repository policy. See https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit [19:30] #link https://docs.google.com/document/d/1apUKR4gtOrfPGCWmtoebaQUhoy-fG8Cyo3VKJyhnpD0/edit# [19:30] I've been making good progress here. I think I'm now running up against needing to speak to individual snap maintainers, and also get a few other bits from other TB members please. [19:30] which bits do you need from us? [19:30] It's all for the snap specific stuff that is Appendix A [19:31] The specifics of how snap channels and branches needs to be documented here. sil2100 had some input, and so does https://wiki.ubuntu.com/UbuntuSeededSnaps [19:32] Next, should we remove cyphesis-cpp and ember and add them to the sync blocklist as they're pulling in snaps? [19:32] I will contact the maintainers first of course. [19:33] is it ok for us to review these questions offline after the meeting? [19:33] But then, does it need to be our policy that it's not OK for us to sync Debian packages that do this without someone in Ubuntu advocating for their inclusion and ensuring that they meet our requirements? [19:33] Sure [19:34] I'll add some comments pointing out these bits to the doc then I guess. [19:35] (done) [19:36] I think the final thing is: are we now ready and committed enough to this plan to start speaking to snap owners on bringing existing snaps into alignment with this draft policy? [19:36] I think so yes [19:36] OK. Thanks! [19:36] I'll start arranging that next. [19:37] Any other comments on this topic? [19:37] #action rbasak to finalize third-party seeded snap security policy [19:37] ACTION: rbasak to finalize third-party seeded snap security policy [19:37] #action vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. [19:37] ACTION: vorlon to circle around with store, snapcraft, et all, and revise the snap source revision policy to be more clear with regards to rebuildability and GPL compliance. [19:37] #topic Scan the mailing list archive for anything we missed (standing item) [19:38] "Reviving the patch pilot program" [19:38] I'm already speaking to Philipp on this and have volunteered my TB hat. [19:38] "Ubuntu Technical Board at the Ubuntu Summit 2022" [19:38] Same here [19:39] "New Official Flavor Process Issues" continues - I'm in touch with those involved. [19:39] I think that's all recent ML activity covered. [19:39] Is there anything I've missed? [19:39] #topic Check up on community bugs (standing item) [19:39] #info [19:39] There are currently no open bugs. [19:39] I haven't yet received a response from seb128. would it be okay if I get the confirmation by tomorrow and then ping y'all to request for a voting? [19:40] rs2009: there's no rush. I'm happy to vote by email. The blocker for my vote is people on the release team (eg. vorlon, sil2100) confirming that they consider you to be ready. [19:41] #topic Select a chair for the next meeting (next from https://launchpad.net/~techboard/+members) [19:41] It'll be sil2100 with cyphermox as backup. [19:41] #topic AOB [19:41] AOB? [19:41] I wanted to check in if you have put some thoughts in to tracking the TB work e.g. on launchpad? [19:42] o/ [19:42] I'd be quite happy with a Launchpad project dedicated to this. [19:43] Khurshid is suggesting that he would be willing to be the official uploader for Ubuntu Unity as a flavor if given universe upload rights [19:44] if that's okay, Khurshid is willing to send a confirmation right away [19:44] rs2009: does Khurshid have upload rights to universe right now already? [19:45] rs2009: that's fine, but first he's got to get those rights. [19:45] rs2009: the policy requires that someone already be approved as an uploader stand for the flavor [19:45] We encourage to apply for MOTU via the DMB if anything! [19:45] There's a process for getting uploader status. It involves demonstrating capability and competency. [19:46] So please do get that - but I don't think you can fulfil this requirement on the new flavour proess without having it first. [19:46] We'd like to help you do that! [19:46] But it's not an immediate thing. [19:47] Khurshid doesn't currently have upload rights, but he's an experienced member and just suggested this so thought of checking with y'all. I'll get a confirmation from seb128 or Dimitri from the Compiz team and get back (will send it to the release team tomorrow) [19:47] rs2009: excellent o/ [19:47] Great. Thanks! [19:47] Any other AOB? [19:48] #endmeeting [19:48] Meeting ended at 19:48:40 UTC. Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-08-30-19.05.moin.txt [19:48] thanks [19:53] Okay, so I guess these are the required steps? [19:53] 1. Get a confirmation from a MOTU willing to be the official uploader for the flavor [19:53] 2. Send the confirmation to the release team (I'll do that tomorrow) [19:53] 3. Inform the TB and request them to do the voting (will do that tomorrow) [19:54] thanks for all your feedback and help :)