Main Inclusion Review (MIR)

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:

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.

Reporter thinks about the package
Reviewers review the bug
Resolve issues

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

To find out more about the team who oversees the MIR process, see our page about the MIR team.

There you will also find information on how to contact them if you have an MIR in progress, or want to submit one, and what to expect from the team.

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.

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.