Skip to content

Mir improvements #34

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
s-makin merged 7 commits into from
Jun 2, 2025
Merged

Mir improvements #34

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
bd42528
delete mir-helpers page
s-makin Jun 2, 2025
69a366e
Delete exceptions page and reassign content
s-makin Jun 2, 2025
ac1ee40
move team meeting content to new page
s-makin Jun 2, 2025
1e512ee
Update with matrix details
s-makin Jun 2, 2025
fc80808
bring together the communication section
s-makin Jun 2, 2025
feb7c8c
rename "exceptions" section
s-makin Jun 2, 2025
931a2e0
nits and fixups
s-makin Jun 2, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions docs/staging/MIR/mir-exceptions-OEM.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,7 @@ This is the subject of a
[discussion with the Technical Board](https://lists.ubuntu.com/archives/technical-board/2020-January/002478.html).
See [OEM Archive](https://wiki.ubuntu.com/OEMArchive) for further details.


## Process

If packages meet the subscriber, naming and content requirements defined below,
Expand All @@ -45,17 +46,20 @@ debdiff against a reference package in the Ubuntu archive. If any of the
differences are not covered in this document or trivially understandable, go
back to the uploader.


## Subscriber

As the packages are going to be in main, they need to have an "owning" team
that is subscribed to the bugs for the package in Launchpad. The team
[~canonical-mainstream](https://launchpad.net/~canonical-mainstream) must be
subscribed to the package before it is promoted.


## Naming

The source and binary packages must follow the form `oem-<product name>-meta`.


## Content

The packages must follow the following structure. They must be otherwise empty.
Expand Down Expand Up @@ -125,6 +129,7 @@ so that the package is auditable. It must use `dh-modalias` to fill in the
end up in `XB-Modaliases` and represents the hardware set that this metapackage
is designed to work with.


## Known modaliases matching patterns

More information about modaliases in OEM meta packages.
Expand Down Expand Up @@ -164,6 +169,7 @@ Matching types:
- Lenovo
```


## Known issue

* [LP#1869867](https://bugs.launchpad.net/ubuntu/+source/oem-qemu-meta/+bug/1869867) gives
Expand Down
16 changes: 16 additions & 0 deletions docs/staging/MIR/mir-exceptions-fonts.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
(mir-exceptions-fonts)=
# Font package exceptions

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 them. Therefore not all of
the process have 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 an 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).
40 changes: 6 additions & 34 deletions docs/staging/MIR/mir-exceptions.md → docs/staging/MIR/mir-exceptions-rereview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,35 +1,5 @@
(mir-exceptions)=
# MIR exceptions

## Font 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 them. Therefore not all of
the process have 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 an 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).

## OEM packages

Starting in 20.04, Ubuntu Desktop ISOs will support installing hardware-specific
meta-packages if the machine being installed on has a corresponding enablement
package available. These packages enable an additional APT archive.

This is the subject of a
[discussion with the Technical Board](https://lists.ubuntu.com/archives/technical-board/2020-January/002478.html).
See [OEM Archive](https://wiki.ubuntu.com/OEMArchive) for further details.

See {ref}`mir-exceptions-oem`.

## Re-reviews
(mir-exceptions-rereview)=
# Re-review exceptions

Historically, if something was in main once, there was no re-evaluation done
later unless teams asked for it based on huge changes. Doing regular
Expand All @@ -55,7 +25,8 @@ tasks to show the state of each review independently.
If source renames are involved, those can be tracked the same way -- all
associated to one bug.

### Renamed or reorganized sources

## Renamed or reorganized sources

We can use some regular events to start with re-reviews at a small scale,
and that is when things pop up on our radar anyway.
Expand All @@ -67,7 +38,8 @@ have gotten a fast-path approval based on being in main already.
But from now on, for packages old enough to not have any audit-trail via an MIR
bug, we want to do a re-evaluation when they show up as a component mismatch.

### Opt-in re-review

## Opt-in re-review

For special cases (read: do not dump hundreds of requests to the MIR team at
once) teams can also request a re-review. That might even be worthwhile if
Expand Down
36 changes: 0 additions & 36 deletions docs/staging/MIR/mir-helpers.md
View file
Open in desktop

This file was deleted.

129 changes: 22 additions & 107 deletions docs/staging/MIR/mir-overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,34 +1,26 @@
# Main Inclusion Review (MIR) process

Packages in Ubuntu {term}`main` (and {term}`restricted`) are officially
Packages in Ubuntu `main` (and `restricted`) are officially
maintained, supported and recommended by the Ubuntu project.
{term}`Canonical` provides security updates, standard support services, and
certain {term}`SLA` guarantees for these packages.
certain SLA guarantees for these packages.

Therefore, special consideration is necessary before adding new packages
to `main` or `restricted`. The [Ubuntu MIR team](https://launchpad.net/~ubuntu-mir)
reviews packages for promotion:

* from {term}`universe` to `main`.
* from {term}`multiverse` to `restricted`.
* from {term}`universe` to {term}`main`.
* from {term}`multiverse` to {term}`restricted`.

The process of reviewing packages before they can be promoted is the
**Main Inclusion Review (MIR)** process.

## The MIR documentation
```{admonition} TODO
:class: important

The guidelines and review process is constantly evolving. Even if you have
submitted a package for Main Inclusion Review in the past, you should still
re-read the MIR documentation.

The MIR documentation is also a living document. External contributions,
suggestions, discussions or questions about the process are always welcome. We
would love to hear from you!
Add `toctrees` on this page
```

To contribute, simply submit a pull request with your changes or create an
issue as described in our {ref}`Contributing guide<contribute>`. Please
also attend the weekly {ref}`MIR Team meeting <mir-team-meeting>` if you want
to discuss your issue with the MIR Team.

## MIR process overview

Expand All @@ -40,6 +32,15 @@ to discuss your issue with the MIR Team.
Add the simplified overview of the MIR state machine diagram here
```

## Communication

The MIR team holds a {ref}`mir-team-meeting` where you can raise issues or
discuss your case with the team.

The {ref}`Service Level Objectives <mir-slo>` page details what you can and
should expect from the reviewers.


## MIR documentation

```{note}
Expand All @@ -51,102 +52,16 @@ reference-- this is not the final format.
* {ref}`mir-templates-and-rules`
* {ref}`mir-file-a-bug`
* {ref}`mir-review-a-bug`
* {ref}`mir-slo`

* {ref}`mir-helpers`

* {ref}`mir-exceptions`
* {ref}`mir-exceptions-oem`

* {ref}`mir-rust`


(mir-team-meeting)=
## MIR team weekly status meeting

The MIR Team holds weekly meetings every Tuesday at
<time datetime="T16:30+01:00">16:30 CET</time> on the {term}`IRC` server
`irc.libera.chat` in the `#ubuntu-meeting` channel. You can follow
[these instructions](https://libera.chat/guides/connect) on how to connect to
`irc.libera.chat`.

The purpose of the meeting is:

* to allocate a fair share of work between each member of the MIR team
* to provide a timely response to reporters of MIR requests
* to detect and discuss any current or complex cases

You should attend these meetings if you submit an MIR request, until it is
approved or rejected.

Due to the nature of the
[Ubuntu Development Process](https://canonical-ubuntu-packaging-guide.readthedocs-hosted.com/en/2.0-preview/explanation/development-process/),
there are times (e.g. close to Feature Freeze) when this meeting is busy and
others (e.g. right after a new release) when it is quieter. Consequently,
response times to MIR requests are (on average) usually faster in those quieter
periods after the release of a new Ubuntu version.

### Meeting structure

In such quiet 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 discussing.

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.

If you're chairing the meeting, you can the following meetingology
template:
## MIR special cases

```
#startmeeting Weekly Main Inclusion Requests status

Ping for MIR meeting - didrocks joalif slyon sarnold cpaelzer mylesjp pushkarnk ( dviererbe )

# Awareness of external agenda items
Mission: To be aware and potentially allocate the required time, poll if anyone attending has discussions that should be added to the agenda today.

#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: Identify required actions and spread the load among the teams

#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 Process/Documentation improvements
Mission: Review pending process/documentation pull-requests or issues

#link https://github.com/canonical/ubuntu-mir/pulls
#link https://github.com/canonical/ubuntu-mir/issues

#topic MIR related Security Review Queue
Mission: Check on progress, do deadlines seem doable?

Some clients can only work with one, some with the other escaping - the URLs point to the same place.
#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&orderby=-date_last_updated&start=0
#link https://bugs.launchpad.net/~ubuntu-security/+bugs?field.searchtext=[MIR]&assignee_option=choose&field.assignee=ubuntu-security&field.bug_reporter=&field.bug_commenter=&field.subscriber=ubuntu-mir&orderby=-date_last_updated&start=0

Internal link
- ensure your teams items are prioritized among each other as you'd expect
- ensure community requests do not get stomped by teams calling for favors too much
#link https://warthogs.atlassian.net/jira/software/c/projects/SEC/boards/594

#topic Any other business?
Mission: catch-all chance for anything missed or not covered by the usual agenda items.
* {ref}`mir-exceptions-fonts`
* {ref}`mir-exceptions-oem`
* {ref}`mir-exceptions-rereview`
* {ref}`mir-rust`

#endmeeting
```



Expand Down
Loading
Loading