MIR roles and steps

MIR series

The article series provides guidance on all aspects of the Main Inclusion Reviews (MIR).

Process:

Contact:

Getting a package promoted to main or restricted through the MIR process generally follows this set of steps, where the progress of the bug is tracked in Launchpad using bug states.

Participants represent particular roles along the steps of the process.

Role overview

There are four roles typically involved in the MIR process, and their participation follows the same order as the steps of the MIR process itself.

  1. Reporter (mir-reporter) is the person who wants a package promoted, who will submit the MIR request through a Launchpad bug.

  2. Reviewer (mir-reviewer) is the MIR team member who reviews the request.

  3. Security reviewer (mir-security-reviewer) for packages where an additional security review is needed.

  4. Archive Admin (archive-admin) who promotes the package after the reviews are completed.

Reporter thinks about the package

The MIR request is submitted as a Launchpad bug by the reporter, who uses the MIR reporter’s template. The reporter is initially expected to:

Process the template

Process the template and check that the package meets all the criteria there. The How to use MIR templates page can provide guidance.

While processing the template, if it turns out that the package has non-trivial problems, it is not yet eligible for main inclusion, and those problems need to be fixed first. In that case, the reporter should:

  • Write down issues that violate the requirements and list them in the MIR bug.

  • Write down all positive checks that were done (not only the issues).

File a bug report

File a bug report about the package, titled “[MIR] sourcepackagename”.

  • Answering each TODO should include a positive or negative statement as confirmation that each requirement was checked carefully.

  • Rule violations should have an explanation to justify why it should be OK for this case.

Subscribe ubuntu-mir to the bug report. Keep it in state “NEW” and do not assign it to anyone: this ensures that it appears in the MIR bug list.

Reviewers review the bug

The MIR bug report is reviewed first by the MIR team reviewer, and then if necessary, also by the security reviewer. Reviewers use the MIR reviewer’s template.

MIR team review

The MIR team reviewer reviews the bug report.

They might delegate portions of the review to other teams, (e.g. the security team) by assigning it to them.

The outcome of the review is either an acknowledgment, or a set of tasks that still need to be completed.

Security review

  • See Security team/Auditing for details on requesting an audit.

  • See the security team Jira board (private board) for a prioritized list of MIR security reviews, or getting sign-off from particular team leads about maintenance commitments.

Update the bug status

After reviewing, the bug status should be adjusted according to the outcome. If there has been more than one review (e.g. by both MIR team and security team reviewers), whoever does the last review shall be the one to adjust the bug status.

For instance, if the MIR team says “OK”, and then Security says “OK”, the Security team reviewer should mark the bug as Fix Committed.

For other statuses, see the Process states page.

Refer back to reporter

If, during the review process, tasks are identified that need to be completed, the bug is set to Incomplete. This reflects that the onus is back on the reporter to drive the completion of those tasks forward before more progress can be made.

Common examples are “please add an automated test” or “this needs the new version”.

Resolve issues

If the bug is set to Incomplete, the reporter needs to resolve the issues and complete any tasks that are still outstanding. The MIR team checks updates on any Incomplete bugs and thereby receives the reporter’s statement on which issues have been handled. The reviewer checks and confirms – once the issues are indeed fully resolved, sets the bug state accordingly to move on with the process.

Now, the reporter takes responsibility for adding the package to the seeds as per Seed management, or adding a dependency to it from another package that already is in main.

The package will not be moved to main automatically, but will show up in the component-mismatches list, or if the dependency is only in proposed, the component-mismatches-proposed list.

At this point, Archive Admins will promote approved packages to main.

Additional notes

  • MIR bugs should always be named for SOURCE packages, not binary packages.

  • New binary packages from existing source packages, where the source package is already in main, do not require new MIR bugs.

  • If a new source package contains only code which is already in main (e.g. a source package split or rename, or source packages with a version in the name), it may not need a full review.

    In such cases, submitting an MIR bug with an explanation (without the full template) or updating/extending an existing MIR bug for the package and re-opening it by setting it to “NEW” is sufficient.

MIR Team Service Level Objectives

Reviews take time, scaling up with the complexity of the case. Sadly it is usually the very complex, very special cases that tend to come in very late – then the submitters are unhappy with the velocity of the review.

For transparency and to manage expectations, we hereby define the Service Level Objectives (SLOs) for this process.

Furthermore, to be clear - you can help!

You know in advance what we will check. History shows that a well-prepared case will pass through more quickly in each phase. By truly caring about tests, quality, warnings and the many other things we check for, you can help increase efficiency. So please take all the statements we ask for seriously and try to fulfill them.

MIR review SLO

While we aim for more when possible, our goal is to assign (in the weekly meeting) one review per active MIR member per week, to come back with the result before the next meeting. On average that means we can handle about 4 cases per week, sometimes more (if we can make the space or they are trivial) and sometimes less (PTO times).

So far this used to be enough, and allowed < 1 week responses for almost all cases for several years now. Except during spikes of everyone dumping huge changes at the last minute right before feature freeze. Try to avoid that phase, to help yourself getting a timely review.

The above of course is for the initial review, if everything is fine and no security review is needed – then that is it and you are done. But findings have to be answered or fixed and, if needed, a security review has to be exercised. The time for this depends on the complexity of the findings – and remember that there have been cases as bad as being rejected, forcing the requester to look for alternative solutions.

Please consider this in your estimations when you plan a contribution.

Security review SLO

Security team MIRs are laborious and require lead time. Make MIR requests as early in a release cycle as possible, ideally well before Feature Freeze. For an MIR to be considered for a release, it must be assigned to the Security team (by the MIR team) before Beta Freeze. This does not guarantee that a security review can be completed by Final Release. Ask the director of Security for exceptions.

The best ways to contact the Security team about MIRs is the MIR / Audits Jira Page or through the Mattermost channels ~mir-security-review-priority or ~security-engineering.

Teams are encouraged to set the relative importance of MIRs they own on the MIR / Audits Jira Page. Security attempts to work across and prioritize all teams equally. Jira priority drives the order we work on MIRs.