Main Inclusion Review (MIR)¶
MIR series
The article series provides guidance on all aspects of the Main Inclusion Reviews (MIR).
Process:
Main Inclusion Review (MIR) - High level overview
MIR roles and steps - Expectations against and steps of reporters and reviewers
Process states - Details how a case moves through this process
How to use MIR templates - Helpers to ease reports and reviews
MIR special cases - Deviations from the normal process:
Contact:
MIR team meeting - Regular meeting of the MIR team
MIR reaching the team - Reaching the MIR team
Packages in Ubuntu main (and restricted) are officially
maintained, supported and recommended by the Ubuntu project.
Canonical provides security updates, standard support services, and
certain Service Level Agreement (SLA) guarantees for these packages.
Therefore, special consideration is necessary before adding new packages
to main or restricted. The Ubuntu MIR team
reviews packages for promotion:
from multiverse to restricted.
Reviewing packages before they can be promoted is the Main Inclusion Review (MIR) process. The purpose of the MIR process is to avoid mistakes that have caused issues in the past and ensure the long-term maintainability of the packages in the Package Archive.
Any package that shall be part of a default Ubuntu installation has to be in main (or restricted) to guarantee a higher level of quality control and maintenance for the default user experience.
Further packages, not installed by default, can also be added via the supported seeds, usually because they represent an important yet optional workload to the Ubuntu userbase.
In general pulling into main is done directly via Seed management or
indirectly via a dependency from something that already is in main.
For something to be allowed into main, all its code and runtime dependencies
must be in main.
In the past, build-dependencies also had to be in generally main, but since
14.04 Trusty that is no longer a hard requirement. This is meant to ease
the burden on tools only e.g. rendering documentation, yet it does not mean “no
build-dependencies are needed” either. Code that is built into the resulting
artifacts even without a dependency to another package in the final packages
metadata shall be in main as well.
This is the default for some ecosystems like rust and go, but also valid for
e.g. C headers if they contain not just definitions but large amounts of
active code that is built into the binaries.
MIR process overview¶
If we reduce the process to its simplest components, it can be described in only three steps.
First, the process makes the reporter think about the package or packages they want to own. Then, the reviewer checks what is submitted and either approves or raises issues. Finally, any such issues are resolved by the reporter, and then the process is complete and the package can be promoted.
This process, and the different participants involved, are outlined in more detail in MIR roles and steps.
In reality, things are often more complex than that! We use Launchpad (and the states of bugs in Launchpad) to track the progress of any main inclusion request as shown in our more detailed Process states breakdown.
About the MIR team¶
The Ubuntu MIR team oversees the Main Inclusion Review (MIR) process. They are responsible for reviewing packages for promotion:
from multiverse to restricted
In the full MIR process there are more roles involved than just the Ubuntu MIR team, see Role overview about that.
If you have an MIR in progress, want to submit one, or are uncertain about the process contact the team in matrix of in their regular meeting. Information on what you can expect from the reviewers is detailed in the Service Level Objectives.
File an MIR bug¶
The MIR process uses templates for both those submitting a request (reporters) and those reviewing requests (reviewers). To make the process as smooth as possible, which benefits everyone, we ask that you familiarize yourself with the process before filing a request.
Reporters: to file a request, use the MIR reporter’s template.
Reviewers: to review a request, use the MIR reviewer’s template.
Whether you are a reporter or a reviewer, new to the MIR process or a seasoned veteran, we have also prepared additional guidance on how to use the templates to make the task of filling out the template as straightforward as possible.
MIR special cases¶
Some packages have reasons not to follow the standard MIR process. This section provides details on these and exceptions.
Exceptions¶
Deviations from the norm¶
Sometimes cases are special and do not follow the normal procedures, those are outlined here.