desktop-common in the platform seed is what all Ubuntu flavors and Ubuntu Desktop pull in to their images. We need to ensure that all parties are aware of the contents of this seed. Additionally, we should also aim to:

• allow affected parties to voice concerns or questions.
• ensure that the rationale for inclusion is clear and agreed upon.
• clearly define a process which a party can appeal to the inclusion of a package in this seed.

The Process

The package you wish to propose inclusion of should already be in Main. If it is not in Main, you need to follow the MainInclusionRequest process.

There are two potential paths which could be followed in the process.

If the package would have a user-facing impact (such as a daemon), an aging process is important to ensure that all factors can be reviewed before being added. To proceed down this route, send an email to the ubuntu-release mailing list which answers the following questions:

1. What is the purpose of this package? What does it do and why is it important to include this by default? Is there a user-facing impact of including this package by default?
2. How long has this package been in Main? Are there any open CVEs or high (or greater) priority bugs, or any other known issues with it?
3. Who takes responsibility for this package and what is the best way to contact them?

At this point, an aging period of one week should be allowed for objections from anyone who includes this seed in their images (including flavors) and/or the party responsible for maintaining the package, which should be emailed to ubuntu-release.

However, if the package does not have a user-facing impact, you are free to add it to the seed immediately, but you must still send an email to the ubuntu-release mailing list answering some or all of the questions above, which at minimum provides justification for its addition.

Whichever path chosen, should an objection be stated on the ubuntu-release mailing list during or after this aging period, an attempt should be made by the team responsible for the package to address or provide an explanation for the issues presented by the opposing party, and both parties should come up with a plan (formally or informally) to resolve the issues. If the issues cannot be resolved, the package needs to be removed from the seed*. In the case that the party opposing a package's inclusion is dissolved (through a flavor becoming active or some other means), the proposal should be restated to the mailing list.

If no objections are stated, the package must be added to the seed, with a link to the proposal on the mailing list in the commit message.

* The Ubuntu Technical Board can override a package's removal or inclusion in this seed.