Packages in Ubuntu main (and restricted) are officially maintained, supported and recommended by the Ubuntu project. Security updates are provided for them as necessary by Canonical, and Canonical's standard support services apply to these packages.
Therefore, special consideration is necessary before adding new packages to these components. The Ubuntu MIR Team reviews packages for promotion from universe to main.
That is the Main Inclusion Review => MIR
This is supposed to be an overview of MIR bug status (as there was enough confusion in the past). Especially to make clear who's turn it is to act next on a MIR bug.
1. New/Confirmed (unassigned)
Bug is new for the MIR team to dispatch it to a MIR Team member
2. New/Confirmed (assigned)
on the TODO list of the assigned MIR team member
3. New/Confirmed (assigned to Security)
on the TODO list of the Security Team
4. In Progress (any)
MIR team ack (and if needed Security Team ack) done, but now needs the Dependency/Seed change to happen to pull it into Main
5. Fix Committed (any)
All of the above done, waiting for an AA to promote the packages
6. Fix Released (any)
Case resolved by an AA
7. Incomplete (any)
Questions/Requests were raised for the bug reporter to resolve/clarify
8. Won't Fix (any)
Final Nack or given up by the bug reporter
9. Invalid (any)
No Feedback for a while when in incomplete status
Answered +-7----------+ No feedback +-9-------+ +------------------+ Incomplete +------------------------> Invalid | | old assign can | any <--------------------+ | any | | be kept as-is +-----^------+ | +---------+ | | question | | | | +-1---v-------+ Triage +-2---+----+ Security needed +-3-+------------------+ | New/Conf +--------->+ New/Conf +----------------->+ New/Conf | | unassigned | | assigned | | assigned to Security | +-------------+ +-+--+--+--+ +-+--+--+--------------+ | | | +-8-----------+ | | | | | +----> Won't Fix <----+ | | | | Nack| any | Nack | | | | +-------------+ | | | | | | | | +-4-----------+ | | | +-------> In Progress <-------+ | | Ack | any | Ack | | +-------------+ | | |Change that pulls | | |into Main | +-6------------+ | +-5-v-----------+ | | Fix Released | +---------> Fix Committed <---------+ | any <---------------------+ any | +--------------+ AA promotes +---------------+
Note1: Since many people set things to confirmed once they are sure it "exists" all too often bugs get set to confirmed. Since confirmed does not have any meaning for our process we will handle new<->confirmed as if the'y be the same.
Note2: All other combinations are undefined and should be fixed up to one of the defined states
Fonts packages given that fonts are just data, there's no way for them to trip any of the problems that would cause us to not want to support it. Therefore not all of the process has to be followed for these. Unfortunately there were cases where src:font-* packages contained way more than just a font - due to that either the MIR Team (if a MIR bug was filed) or the Ubuntu-Archive team (on promoting it) has to do a spot check that neither the source nor the created binary packages violate these assumptions.
The only limitation is that the package needs a valid team subscriber before being promoted by an archive admin - just in case anything might come up later. The MIR Team should try to clarify that with the Team that owns the depending package to own the font as well (read: without the overhead of a full MIR process).
Filing a MIR bug
The steps of the MIR process require a reporter (the one who wants a package promoted) a MIR team member (who does the review) and potentially a Security team member (for an extra review).
The MIR-bug reporter is expected to:
Thoroughly go through TODO/RULE entries in Ubuntu Main Inclusion RULEs and TODOs, check that the package meets all the points there. If this package has nontrivial problems, it is not eligible for main inclusion, and needs to be fixed first.
- Write down issues that violate the requirements and list them in the MIR bug
- Write down all positive checks that you did as well (not only the issues)
- File a bug report about the package, titled "[MIR] sourcepackagename".
use below template from Ubuntu Main Inclusion RULEs and TODOs
- For each rule include a positive or negative statement as confirmation that you checked each requirement carefully.
- For any rule violations ensure to explain 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!), so that it appears in the MIR bug list.
The MIR team reviews the reports, and sets acceptable ones to In Progress or Fix Committed. They might also delegate portions of the review to other teams, by assigning it to them; common cases are getting a thorough security review from the security team (please see SecurityTeam/Auditing for details on requesting an audit and the security team trello board (private board; Reviews lane) for prioritized list of MIR security reviews), or getting a sign-off from particular team leads about maintenance commitments.
- In the case where an MIR needs a security review, a normal MIR review will happen by a member of the MIR team and the security review by a member of the security team. Among these team members, whoever does the last review shall adjust the bug status accordingly. For instance, if MIR team says ok then security says ok, the security team member should mark the bug as Fix Committed (see above for other statuses).
- In case the MIR Team (or later other reviewers) identify tasks that need to be done the bug is set to "incomplete" to reflect that is back on the reporter to drive that forward before more progress can be made. Common Examples are "please add an automated test" or "this needs the new version"
1. The submitter should then take responsibility for adding the package to the seeds as per SeedManagement 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.
Archive administrators will review the component-mismatches output, and for each package waiting to move into main, look for a corresponding bug.
The archive administrators will promote approved packages to main if some other package or the seeds want it (see component-mismatches output) and the package in question has an owning team subscribed to it.
- 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 MIR bugs.
- If a new source package contains only code which is already in main (e.g. the result of a source package split or rename, or source packages with a version in the name), it may not need a full review. Submitting a MIR bug with an explanation (but without the full template) or updating/extending on the existing old MIR bug and re-opening it by setting it to "NEW" is sufficient.
Templates and Rules
It is the task of the reporter/reviewer to evaluate all the entries listed in RULE sections and based on that to answer or adapt all TODO entries to create the content for the MIR request or the review feedback respectively.
The sum of RULE sections is not meant to be complete without the TODO entries. Only combined they define the full rules as that allows to avoid duplication.
On one hand the TODO entries shall cover everything we expect from a report. These shall help to create a concise yet complete content of each report/review.
On the other hand the RULE entries provide additional background, details, options and interpretation help.
In many cases where rules are rather simple they only appear as TODO as they do not need additional explanation.
The reporter/reviewer is tasked to use the templates the following way:
- Copy the full template below into an editor of your choice
Read the lines starting with RULE for all aspects of the MIR
For each line marked with TODO
- Adapt the line to provide the correct answer matching the package(s) that you request.
In some of those lines you'll need to replace placeholders '<TBD>' with whatever matches your request
Remove the TODO prefix when you are sure you answered a statement
Some TODO lines can just be removed if they do not apply to the case, for example if you do not have "additional reasons" to state
- Sometimes mutually exclusive options are provided like "link to CVE" or "no security issues in the past", leave only those statements that apply.
To assist the template-user those alternatives are marked like TODO-A:, TODO-B:, .... Of those one would usually expect only one to remain in the final content.
The MIR Team reviewer will have to judge, therefore all his statements start in an OK: section. But any time a violation is found the statement is moved to the Problems: area and flagged what is missing/expected. If no Problems: are present leave just the alternative Problems: None for posting the review.
Remove the lines starting with RULE after you have processed them
- Eventually all you will have left are the categories Availability, Rationale, ... and therin the answers that the MIR process expects
- You can and are encouraged to always add more details/background that make the case comprehensible
- Update the MIR Bug
- Reporter: File the MIR bug based on the processed template as the bug description
In case of a single context/reasoning, but multiple packages to promote please provide the full content for each of them separated with --- --- --- --- ---. Be warned that Launchpad can only handle a certain amount of such tasks well, as a best practise if you have more than 10 packages consider splitting things into multiple bugs with one central one for tracking referencing all the others.
- MIR-Team: Review and add a comment to the bug that contains the review
- In case of a single context/reasoning, but multiple packages MIR reviewers will do one review post per such package.
- Reporter: File the MIR bug based on the processed template as the bug description
Main Inclusion requirements
Use this template for the MIR bug report that you will file.
Usage follows Templates and Rules.
The package must fulfill the following requirements.
[Availability] TODO: The package <TBD> is already in Ubuntu universe. TODO: The package <TBD> builds for the architectures it is designed to work on. TODO: It currently builds and works for architectures: <TBD> TODO: Link to package [[https://launchpad.net/ubuntu/+source/<TBD>|<TBD>]] [Rationale] RULE: There must be a certain level of demand for the package TODO: - The package <TBD> is required in Ubuntu main for <TBD> TODO-A: - The package <TBD> will generally be useful for a large part of TODO-A: our user base TODO-B: - The package <TBD> will not generally be useful for a large part of TODO-B: our user base, but is important/helpful still because <TBD> TODO: - Additional reasons <TBD> TODO: - Additionally new use-cases enabled by this are <TBD> TODO: - Package <TBD> covers the same use case as <TBD>, but is better TODO: because <TBD>, thereby we want to replace it. TODO: - The package <TBD> is a new runtime dependency of package <TBD> that TODO: we already support RULE: Reviews will take some time. Also the potential extra work out of review RULE: feedback from either MIR-team and/or security-team will take time. RULE: For better priorization it is quite helpful to clearly state the RULE: target release and set a milestone to the bug task. RULE: When doing so do not describe what you "wish" or "would like to have". RULE: Only milestones that are sufficiently well-founded and related to RULE: major releases will be considered TODO-A: - The package <TBD> is required in Ubuntu main no later than <TBD> TODO-A: due to <TBD> TODO-B: - It would be great and useful to community/processes to have the TODO-B: package <TBD> in Ubuntu main, but there is no definitive deadline. [Security] RULE: The security history and the current state of security issues in the RULE: package must allow us to support the package for at least 9 months (120 RULE: for LTS+ESM support) without exposing its users to an inappropriate level RULE: of security risks. This requires checking of several things: RULE: - Search in the National Vulnerability Database using the PKG as keyword RULE: http://cve.mitre.org/cve/search_cve_list.html RULE: - check OSS security mailing list (feed into search engine RULE: 'site:www.openwall.com/lists/oss-security <pkgname>') RULE: - Ubuntu CVE Tracker: https://ubuntu.com/security/cve?package=<source-package-name> TODO-A: - Had #<TBD> security issues in the past TODO-A: - <TBD> links to such security issues in trackers TODO-A: - <TBD> to any context that shows how these issues got handled in TODO-A: the past TODO-B: - No CVEs/security issues in this software in the past RULE: - Check for security relevant binaries and behavior. RULE: If any are present, this requires a more in-depth security review. TODO: - no `suid` or `sgid` binaries TODO-A: - no executables in `/sbin` and `/usr/sbin` TODO-B: - Binary <TBD> in sbin is no problem because <TBD> TODO-A: - Package does not install services, timers or recurring jobs TODO-B: - Package does install services, timers or recurring jobs TODO-B: <TBD> (list services, timers, jobs) TODO-C: - Package does install services, timers or recurring jobs TODO-C: <TBD> (list services, timers, jobs) TODO-C: Those have the following security features: <TBD> (add details like TODO-C: reduced permissions, temp environment, restricted users/groups, TODO-C: seccomp, apparmor, ...) TODO: - Packages does not open privileged ports (ports < 1024) TODO: - Packages does not contain extensions to security-sensitive software TODO: (filters, scanners, plugins, UI skins, ...) [Quality assurance - function/usage] RULE: - After installing the package it must be possible to make it working with RULE: a reasonable effort of configuration and documentation reading. TODO-A: - The package works well right after install TODO-B: - The package needs post install configuration or reading of TODO-B: documentation, there isn't a safe default because <TBD> [Quality assurance - maintenance] RULE: - To support a package, we must be reasonably convinced that upstream RULE: supports and cares for the package. RULE: - The status of important bugs in Debian, Ubuntu and upstream's bug RULE: tracking systems must be evaluated. Important bugs must be pointed out RULE: and discussed in the MIR report. TODO: - The package is maintained well in Debian/Ubuntu and has not too many TODO: and long term critical bugs open TODO: - Ubuntu https://bugs.launchpad.net/ubuntu/+source/<TBD>/+bug TODO: - Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=<TBD> TODO: - The package has important open bugs, listing them: <TBD> TODO-A: - The package does not deal with exotic hardware we cannot support TODO-B: - The package does deal with exotic hardware, it is present at <TBD> TODO-B: to be able to test, fix and verify bugs [Quality assurance - testing] RULE: - The package must include a non-trivial test suite RULE: - it should run at package build and fail the build if broken TODO-A: - The package runs a test suite on build time, if it fails TODO-A: it makes the build fail, link to build log <TBD> TODO-B: - The package does not run a test suite at build time because <TBD> RULE: - The package should, but is not required to, also contain RULE: non-trivial autopkgtest(s). TODO-A: - The package runs an autopkgtest, and is currently passing on TODO-A: this <TBD> list of architectures, link to test logs <TBD> TODO-B: - The package does not run an autopkgtest because <TBD> RULE: - existing but failing tests that shall be handled as "ok to fail" RULE: need to be explained along the test logs below TODO-A: - The package does have no failing autopkgtests right now TODO-B: - The package does have failing autopkgtests tests right now, but since TODO-B: they always failed they are handled as "ignored failure", this is TODO-B: ok because <TBD> RULE: - If no build tests nor autopkgtests are included, and/or if the package RULE: requires specific hardware to perform testing, the subscribed team RULE: must provide a written test plan in a comment to the MIR bug, and RULE: commit to running that test either at each upload of the package or RULE: at least once each release cycle. In the comment to the MIR bug, RULE: please link to the codebase of these tests (scripts or doc of manual RULE: steps) and attach a full log of these test runs. This is meant to RULE: assess their validity (e.g. not just superficial) TODO: - The package can not be tested at build or autopkgtest time because <TBD> TODO: to make up for that here <TBD> is a test plan/automation and example TODO: test <TBD> (logs/scripts) RULE: - In some cases a solution that is about to be promoted consists of RULE: several very small libraries and one actual application uniting them RULE: to achieve something useful. This is rather common in the go/rust space. RULE: In that case often these micro-libs on their own can and should only RULE: provide low level unit-tests. But more complex autopkgtests make no RULE: sense on that level. Therefore in those cases one might want to test on RULE: the solution level. RULE: - Process wise MIR-requesting teams can ask (on the bug) for this RULE: special case to apply for a given case, which reduces the test RULE: constraints on the micro libraries but in return increases the RULE: requirements for the test of the actual app/solution. RULE: - Since this might promote micro-lib packages to main with less than RULE: the common level of QA any further MIRed program using them will have RULE: to provide the same amount of increased testing. TODO: - This package is minimal and will be tested in a more wide reaching TODO: solution context <TBD>, details about this testing are here <TBD> [Quality assurance - packaging] RULE: - The package uses a debian/watch file whenever possible. In cases where RULE: this is not possible (e.g. native packages), the package should either RULE: provide a debian/README.source file or a debian/watch file (with RULE: comments only) providing clear instructions on how to generate the RULE: source tar file. TODO-A: - debian/watch is present and works TODO-B: - debian/watch is not present, instead it has <TBD> TODO-C: - debian/watch is not present because it is a native package RULE: - It is often useful to run `lintian --pedantic` on the package to spot RULE: the most common packaging issues in advance RULE: - Non-obvious or non-properly commented lintian overrides should be RULE: explained TODO: - This package does not yield massive lintian Warnings, Errors TODO: - Link to recent build log including a lintian run <TBD> TODO-A: - Lintian overrides are not present TODO-B: - Lintian overrides are present, but ok because <TBD> RULE: - The package should not rely on obsolete or about to be demoted packages. RULE: That currently includes package dependencies on Python2 (without RULE: providing Python3 packages), and packages depending on GTK2. TODO: - This package does not rely on obsolete or about to be demoted packages. TODO: - This package has no python2 or GTK2 dependencies RULE: - Debconf questions should not bother the default user too much TODO-A: - The package will be installed by default, but does not ask debconf TODO-A: questions higher than medium TODO-B: - The package will not be installed by default RULE - The source packaging (in debian/) should be reasonably easy to RULE: understand and maintain. TODO-A: - Packaging and build is easy, link to d/rules <TBD> TODO-B: - Packaging is complex, but that is ok because <TBD> [UI standards] TODO-A: - Application is not end-user facing (does not need translation) TODO-B: - Application is end-user facing, Translation is present, via standard TODO-B: intltool/gettext or similar build and runtime internationalization TODO-B: system see <TBD> TODO-A: - End-user applications that ships a standard conformant desktop file, TODO-B: see <TBD> TODO-B: - End-user applications without desktop file, not needed because <TBD> [Dependencies] RULE: - In case of alternative the preferred alternative must be in main. RULE: - Build(-only) dependencies can be in universe RULE: - If there are further dependencies they need a separate MIR discussion RULE: (this can be a separate bug or another task on the main MIR bug) TODO-A: - No further depends or recommends dependencies that are not yet in main TODO-B: - There are further dependencies that are not yet in main, MIR for them TODO-B: is at <TBD> TODO-C: - There are further dependencies that are not yet in main, the MIR TODO-C: process for them is handled as part of this bug here. [Standards compliance] RULE: - Major violations should be documented and justified. RULE: - [[https://refspecs.linuxfoundation.org/fhs.shtml|FHS]] RULE: - [[http://www.debian.org/doc/debian-policy/|Debian Policy]] TODO-A: - This package correctly follows FHS and Debian Policy TODO-B: - This package violates FHS or Debian Policy, reasons for that are <TBD> [Maintenance/Owner] RULE: The package must have an acceptable level of maintenance corresponding RULE: to its complexity: RULE: - All packages must have a designated "owning" team, regardless of RULE: complexity, which is set as a package bug contact. This is not a RULE: requirement for the MIR team ACK, but for the package to be promoted RULE by an archive admin. Still, it is strongly suggested to subscribe, RULE: as the owning team will get a preview of the to-be-expected incoming RULE: bugs later on. RULE: - Simple packages (e.g. language bindings, simple Perl modules, small RULE: command-line programs, etc.) might not need very much maintenance RULE: effort, and if they are maintained well in Debian we can just keep them RULE: synced. They still need a subscribing team to handle bugs, FTBFS and RULE: tests RULE: - More complex packages will usually need a developer or team of RULE: developers paying attention to their bugs, whether that be in Ubuntu RULE: or elsewhere (often Debian). Packages that deliver major new headline RULE: features in Ubuntu need to have commitment from Ubuntu developers RULE: willing to spend substantial time on them. TODO: - Owning Team will be <TBD> TODO-A: - Team is already subscribed to the package TODO-B: - Team is not yet, but will subscribe to the package before promotion RULE: - Responsibilities implied by static builds promoted to main, which is RULE: not a recommended but a common case with golang packages. RULE: - the security team will track CVEs for all golang packages in main RULE: - the security team will provide updates to main for all `golang-*-dev` RULE: packages RULE: - the security team will provide updates to main for golang applications RULE: whose non-vendored source code is affected as per normal procedures RULE: (including e.g., sponsoring/coordinating uploads from teams/upstream RULE: projects, etc) RULE: - the security team will perform no-change-rebuilds for all packages RULE: Built-Using `golang-*-dev` packages it has provided, and coordinate RULE: testing with the owning teams responsible for the rebuilt packages RULE: - for packages that build using any `golang-*-dev` packages: RULE: - the owning team must state their commitment to test RULE: no-change-rebuilds triggered by a dependent library/compiler and to RULE: fix any issues found for the lifetime of the release (including ESM RULE: when included) RULE: - the owning team must provide timely testing of no-change-rebuilds RULE: from the security team, fixing the rebuilt package as necessary RULE: - for packages that build with approved vendored code: RULE: - the owning team must state their commitment to provide updates to RULE: the security team for any affected vendored code for the lifetime of RULE: the release (including ESM when included) RULE: - the security team will alert the owning team of issues that may RULE: affect their vendored code RULE: - the owning team will provide timely, high quality updates for the RULE: security team to sponsor to fix issues in the affected vendored code RULE: - if subsequent uploads add new vendored components or dependencies RULE: these have to be reviewed and agreed by the security team. TODO-A: - This does not use static builds TODO-B: - The team <TBD> is aware of the implications by a static build and TODO-B: commits to test no-change-rebuilds and to fix any issues found for the TODO-B: lifetime of the release (including ESM) TODO-A: - This does not use vendored code TODO-B: - The team <TBD> is aware of the implications of vendored code and (as TODO-B: alerted by the security team) commits to provide updates to the security TODO-B: team for any affected vendored code for the lifetime of the release TODO-B: (including ESM). [Background information] RULE: - The package descriptions should explain the general purpose and context RULE: of the package. Additional explanations/justifications should be done in RULE: the MIR report. RULE: - If the package was renamed recently, or has a different upstream name, RULE: this needs to be explained in the MIR report. TODO: The Package description explains the package well TODO: Upstream Name is <TBD> TODO: Link to upstream project <TBD> TODO: <TBD> (any further background that might be helpful
Reviewing a bug
This section is a guideline for the review by the MIR Team.
Usage follows Templates and Rules.
The Intent is to answer the primary decision "Will this package be well maintained in main?"
By default statements are in the OK section, but issues that need to be addressed should go to the Problem: sections (and briefly the summary at the top).
MIR Team weekly status meeting
The MIR Team holds weekly meetings on Tuesdays, at 4.30 PM CET, in #ubuntu-meeting.
If you're chairing the meeting, you can the following meetingology template:
#startmeeting Weekly Main Inclusion Requests status ping slyon, didrocks, sarnold, joalif, jamespage for MIR meeting Use the #action command to note something for someone to do (optional) #topic Review of previous action items #topic current component mismatches Mission: Identify required actions and spread the load among the teams #link https://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg #link https://people.canonical.com/~ubuntu-archive/component-mismatches.svg #topic New MIRs Mission: ensure to assign all incoming reviews for fast processing #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 #topic Incomplete bugs / questions Mission: discuss the recent activity to identify any follow up action #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 #topic MIR related Security Review Queue Mission: Check on progress, do deadlines seem doable? #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 #topic Any other business? #endmeeting
The meeting is meant to help to facilitate
- a fair share of work for each of us
- a timely response to reporters of MIR requests
- detection and discussion of any current or complex cases
Due to the nature of this process there are times when this is very busy and the meeting is strongly needed. But there are other times (e.g. at the beginning of a new release) where not a lot is happening. In such "idle" phases the leader of the meeting can pre-check the links we usually check together and skip steps of the agenda quoting that a pre-check has not shown anything worth to discuss.
From there we can then go rather directly to "Any other business?" which serves as a catch all for all attendees. By that we can make the meeting more efficient in those times, instead of filing a monologue-log every week.
MIR related helpers
check-mir can be run from a checked out source and tell you which dependencies are in universe.
seeded-in-ubuntu PACKAGE can tell you whether and how a given PACKAGE is seeded
reverse-depends can tell you reverse source or binary depends, per component
Making Life Easier for Archive Team Members
To help prevent promotion of packages that cause component mismatches, we can do two things:
Run check-mir and make sure that all dependencies have a MIR. We don't want to be surprised by a dependency after a package is promoted.
List all distinct binary packages that should be promoted. Often a source package will have binary packages that aren't actually needed in main. Things like -doc, -autopilot or -dbgsym. These can stay in universe, and it is a kindness to list only the packages we need for the archive team member that does the promotion.
- Recommend the owning team to add their corresponding team bug subscriber during the MIR process.