Strawman: merge main and universe

[Matt Zimmerman]

On Wed, Dec 12, 2007 at 10:24:56PM +0000, Scott James Remnant wrote:
> The distinction between main and universe is instead done based on
> "support".  But what does this actually mean?

Our terminology on this needs a bit of cleanup, but the relevant distinction
here is "maintenance".  This means that, for example, a security
vulnerability in the package will be fixed, and this is backed up by a
commitment from Canonical (which has dedicated resources to this
maintenance).

> What about support for fixing bugs?  We actually don't like to do that
> very much, we only have limited updates to our stable release.  This
> surprises most people who think this is what support means.

We do need to do a better job of both communicating our maintenance
practices and ensuring that they meet expectations.  There is work in
progress to change this for 8.04 LTS.

> We move all packages from universe into main, and remove the universe
> component.  Likewise packages from multiverse are moved into restricted,
> and multiverse removed.
> 
> Instead, we define who provides what kind of support through meta-data.
>
> We have generated lists of packages already, the seeds.  In fact, it's
> these seeds that (by a manual process) result in packages being divided
> between main and universe right now.
> 
> So let's just use these to determine the types of support provided.

This seems sensible to me; Debian-style components are unwieldy to work
with, as they are closely tied to the way the archive is published.  We
should be able to change a declaration of maintenance without moving files
around on a web server, and the placement of the files isn't a very good way
of communicating this information.

> Canonical can declare that it provides commercial support for the
> ubuntu-desktop, ubuntu-server, ubuntu-mobile and kubuntu-desktop seeds
> (and any others we support that I forgot).  It can also declare what
> date that support ends.
> 
> Other companies and groups can declare their own support based on the
> existing seeds, or just branch the bzr repository and make their own
> (the seeds are public, and the tool to generate complete package lists
> is also public).
> 
> The Ubuntu Security team can declare which seeds they provide security
> support for at which levels.

All reasonable.

> The packaging tools can then use this information to show appropriate
> information to the user; they'll know the package they are installing is
> supported for a further 12 months by Canonical, a further 18 months by
> another company or group; Security support is provided by the Ubuntu
> security team for 12 months and critical bug fixes are no longer
> provided.

This is tricky.  In order to be effective, this needs to be communicated all
the way from apt-cache up through gnome-app-install in a reasonably
consistent way.

> What about upload privileges?
> 
> Let's do those the same way.

Sounds elegant enough, though I wonder about automatically granting upload
privileges based on a new dependency.

-- 
 - mdz