MainInclusionProcess

Differences between revisions 1 and 27 (spanning 26 versions)
Revision 1 as of 2007-01-26 10:53:02
Size: 1555
Editor: scandic759
Comment: create
Revision 27 as of 2016-11-17 20:17:24
Size: 3234
Editor: barry
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Do you [[http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg|need a MIR]]?
Line 5: Line 7:
 1. Hold any necessary discussion on `ubuntu-devel`
 1. Write a report showing that the package meets the UbuntuMainInclusionRequirements and add it here. You should use the MainInclusionReportTemplate template for the report.
 1. Add this report to the UbuntuMainInclusionQueue.
 1. Add the package to a seed, or as a (build-)dependency of a package in `main`. The package will not be moved to main automatically, but will show up in the output of [http://people.ubuntu.com/~cjwatson/anastacia.txt anastacia].
 1. Archive administrators will review the anastacia output, and for each package waiting to move into `main`, look for a corresponding report filed here
 1. If the report exists and is acceptable, the package will be moved to `main`
 1. Thoroughly go through UbuntuMainInclusionRequirements, check that the package meets all the points there. Write down issues that violate the requirements. If this package has nontrivial problems, it is not eligible for main inclusion, and needs to be fixed first.
 1. File a bug report about the package, titled "[MIR] sourcepackagename". Include the rationale and description of the violations of UbuntuMainInclusionRequirements, and a confirmation that you checked the requirements carefully.
 1. Subscribe `ubuntu-mir` to the bug report (do not assign it to anyone), so that it appears in the [[https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs|MIR bug list]].
 1. The [[https://launchpad.net/~ubuntu-mir|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, assign it to them, and set it to ''Incomplete''; common cases are getting a thorough security review from the [[https://launchpad.net/~ubuntu-security|security team]] (please see [[SecurityTeam/Auditing|SecurityTeam/Auditing]] for details on requesting an audit), or getting a sign-off from particular team leads about maintenance commitments.
 1. Add the package to a [[SeedManagement|seed]], or as a (build-)dependency of a package in `main`. The package will not be moved to main automatically, but will show up in the [[http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt|component-mismatches]] list.
 1. Archive administrators will review the component-mismatches output, and for each package waiting to move into `main`, look for a corresponding [[https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs|bug]].
 1. The submitter should then take responsibility for adding the package to the seeds as per SeedManagement or adding a dependency to it.
 1. The archive administrators will promote approved packages to `main` if some other package or the seeds want it (see [[http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt|component-mismatches output]]).
Line 15: Line 19:
 * New binary packages from existing source packages, where the source package is already in main, do not require reports and do not need to be listed here
 * If a new source package contains only code which is already in main (e.g., the result of a source package split), it may not need a full report, but it should be listed here with a short explanation
 * New binary packages from existing source packages, where the source package is already in main, do not require reports.
 * 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 bug with an explanation is sufficient.

Use this template for the MIR bug report:

[Availability]

[Rationale]

[Security]

[Quality assurance]

[Dependencies]

[Standards compliance]

[Maintenance]

[Background information]

----
CategoryProcess

Do you need a MIR?

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.

  1. Thoroughly go through UbuntuMainInclusionRequirements, check that the package meets all the points there. Write down issues that violate the requirements. If this package has nontrivial problems, it is not eligible for main inclusion, and needs to be fixed first.

  2. File a bug report about the package, titled "[MIR] sourcepackagename". Include the rationale and description of the violations of UbuntuMainInclusionRequirements, and a confirmation that you checked the requirements carefully.

  3. Subscribe ubuntu-mir to the bug report (do not assign it to anyone), so that it appears in the MIR bug list.

  4. 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, assign it to them, and set it to Incomplete; common cases are getting a thorough security review from the security team (please see SecurityTeam/Auditing for details on requesting an audit), or getting a sign-off from particular team leads about maintenance commitments.

  5. Add the package to a seed, or as a (build-)dependency of a package in main. The package will not be moved to main automatically, but will show up in the component-mismatches list.

  6. Archive administrators will review the component-mismatches output, and for each package waiting to move into main, look for a corresponding bug.

  7. The submitter should then take responsibility for adding the package to the seeds as per SeedManagement or adding a dependency to it.

  8. The archive administrators will promote approved packages to main if some other package or the seeds want it (see component-mismatches output).

Notes:

  • Reports 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 reports.
  • 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 bug with an explanation is sufficient.

Use this template for the MIR bug report:

[Availability]

[Rationale]

[Security]

[Quality assurance]

[Dependencies]

[Standards compliance]

[Maintenance]

[Background information]


CategoryProcess

MainInclusionProcess (last edited 2020-09-22 06:41:03 by paelzer)