New component-mismatches for source universe -> main
The following universe packages have new reverse dependencies in main or got seeded. They need to get a MainInclusionReport and be promoted, or the reverse dependencies in main need to be dropped: MIR: #2038942 (Fix Committed) [MIR] protection-domain-mapper & qrtr MIR: #2038942 (Fix Committed) [MIR] protection-domain-mapper & qrtr Please see https://ubuntu-archive-team.ubuntu.com/component-mismatches.txt for the full report. Please contact https://launchpad.net/~ubuntu-archive for problems with this notification. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: ubuntu-advantage-tools SRU exception policy review
On Thu, Oct 05, 2023 at 12:30:31AM +0100, Robie Basak wrote: > [adding Technical Board to Cc] > On Thu, Sep 14, 2023 at 05:39:50PM +0100, Robie Basak wrote: > > This is now ready for feedback and review. We will need sign-offs from > > the Pro client developers (the subset of the Server Team that is > > maintaining this package) as well as the SRU team, Release Team and > > Technical Board. Please see the wiki page for details. > There's been no feedback, and I understand the SRU team are generally > happy with this. So can we move to sign-offs, please? > Release team: please sign off on "Feature freeze in the development > release shall not apply". > Technical board: please sign off on "Facilities that enable access to > Ubuntu Pro may be added to the main Ubuntu archive and installed by > default." and "Updates shall be permitted as usual for SRUs and > additionally after EoSS." (IOW, that we do SRUs into the main archive > after EoSS as an exception here at all). > On behalf of the SRU team I can sign off on the SRU team bits. > Reference document: https://wiki.ubuntu.com/UbuntuAdvantageToolsUpdates This was voted on at today's Technical Board meeting and has been approved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
New component-mismatches for source universe -> main
The following universe packages have new reverse dependencies in main or got seeded. They need to get a MainInclusionReport and be promoted, or the reverse dependencies in main need to be dropped: MIR: #2038942 (Confirmed for Ubuntu Security Team) [MIR] protection-domain-mapper & qrtr MIR: #2038942 (Confirmed for Ubuntu Security Team) [MIR] protection-domain-mapper & qrtr Please see https://ubuntu-archive-team.ubuntu.com/component-mismatches.txt for the full report. Please contact https://launchpad.net/~ubuntu-archive for problems with this notification. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
New component-mismatches for source universe -> main
The following universe packages have new reverse dependencies in main or got seeded. They need to get a MainInclusionReport and be promoted, or the reverse dependencies in main need to be dropped: MIR: #2038942 (New for Dimitri John Ledkov) [MIR] protection-domain-mapper & qrtr MIR: #2038942 (New for Dimitri John Ledkov) [MIR] protection-domain-mapper & qrtr Please see https://ubuntu-archive-team.ubuntu.com/component-mismatches.txt for the full report. Please contact https://launchpad.net/~ubuntu-archive for problems with this notification. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
New component-mismatches for source universe -> main
The following universe packages have new reverse dependencies in main or got seeded. They need to get a MainInclusionReport and be promoted, or the reverse dependencies in main need to be dropped: o protection-domain-mapper: protection-domain-mapper [Reverse-Depends: Ubuntu.Mantic desktop-minimal seed] o qrtr: libqrtr-dev libqrtr1 qrtr-tools [Reverse-Depends: Rescued from qrtr, Ubuntu.Mantic desktop-minimal seed, protection-domain-mapper] Please see https://ubuntu-archive-team.ubuntu.com/component-mismatches.txt for the full report. Please contact https://launchpad.net/~ubuntu-archive for problems with this notification. -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Re: Documenting the ubuntu-sru team membership process
Hi! On Tue, Oct 10, 2023 at 03:27:46PM +0200, Sebastien Bacher wrote: > I've an action items from the TB to reach out to the concerned teams to ask > if they could provide a such documentation, which is why I'm writing to you > now. I agree that we should have some documented process and policy. I've been working on improving SRU documentation in general, including on this aspect, but that's still a work in progress. For onboarding new members of the SRU team, I have been using some draft documentation that I've copied below. This has been consulted by SRU team members to make progress in onboarding for now, but has not yet been considered final. I'd be happy to move this draft to somewhere publicly maintained. I welcome feedback. We could then make sure we have SRU team consensus and make it final. I would expect that the SRU team would remain in control of the text and change it as they feel appropriate in the future - whether that would be fine refinements or major changes. As one member of the Technical Board, I would prefer to see all teams manage the details of their own policies and processes in this way, with the Technical Board only defining what is expected in terms of outcomes. So, to be clear, using the Backporters team as an example as they've already been through a similar exercise, I think that the TB should define a separate text similar to https://wiki.ubuntu.com/TechnicalBoard#Backporters_Team but for the SRU team, and the text below would be internal (but public) process documentation for the SRU team, just as the Backporters team have their own process and policy documentation that they maintain themselves. Robie --- DRAFT FOLLOWS --- # Process for adding members to the team * Existing SRU team members identify when new team members are needed. They will privately nominate suitable candidates, with regard to their availability (eg. a discussion with their manager may be required). * One existing team member will study a candidate’s recent SRU activity, assess them against our criteria and write a summary. * The team will then decide whether the candidate is suitable. * One existing team member will onboard a given new trainee, “sponsoring” privileged SRU actions such as review accept and release. * This mentor will consult with other existing team members and the trainee will be given equivalent privileges when appropriate. ## Criteria for new SRU team members ### Hard requirements * Must be able to upload all SRUs they expect to review; ie. Ubuntu Core Developer or SRU Developer. A member of the SRU team who is an SRU Developer is expected to be in the process of applying to be an Ubuntu Core Developer: the role involves exercising judgement about whether a change in the development series is good, and therefore someone in this role should be formally trusted by the project to make such decisions for the development series as well. * Recent track record of good quality SRUs. * Recent uploads (whether sponsored or not) either met our expectations or successfully anticipated concerns that could reasonably have been predicted by existing SRU team members. * Few recent poor quality SRUs (nice to have: none). This includes uploads for issues that are unsuitable for SRU, as well as missing SRU information, missing bug references, poorly completed SRU information, etc. Exception: if an omission or concern is called out by the uploader and the upload was for the purpose of asking the SRU team about it. * Can they say no? ### Nice to haves * Demonstrated familiarity across existing SRU policies and procedures (rather than just having correctly submitted good SRUs that might be limited in parts of SRU policy and procedure that they exercise) * What about SRUs they’ve sponsored: do they successfully raise the quality of SRU submissions to our expected level before they sponsor them? If so, then this might be a good indicator that they’ll be able to do similar at SRU review time. * Do they have a track record of spotting issues before they occur? How broadly do they look when determining “Where problems could occur”? Do they then make sure the Test Plan covers identified risks? * Do they seek to change general policy when appropriate, rather than ignoring it? Can they identify the difference between individual exceptions and the general case? signature.asc Description: PGP signature -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
Documenting the ubuntu-sru team membership process
Dear Ubuntu SRU Team members, I've started a discussion [1] at the TB level about the fact that some of the Ubuntu project teams don't really communicate on how they are working, especially on how they select new members, which I think is detrimental to the project. During one of the recent TB meetings [2] we went to an agreement that it would be nice if the core project teams could at least document their membership process. We could then add the references https://wiki.ubuntu.com/TechnicalBoard#Team_Delegations. I've an action items from the TB to reach out to the concerned teams to ask if they could provide a such documentation, which is why I'm writing to you now. Let me know if I can help with the process. Thanks in advance, Sébastien Bacher [1] https://lists.ubuntu.com/archives/technical-board/2023-June/002741.html [2] https://irclogs.ubuntu.com/2023/07/11/%23ubuntu-meeting.html -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
