Strawman: merge main and universe

[Scott James Remnant]

I'd like to make a strawman proposal to be torn apart and burnt as
necessary: merge main and universe.  I will try and explain my
rationale, and my alternate proposal.

(I'm subscribed to all of the mailing lists I'm posting to, please don't
Cc me if you're following up to one of them)


The distinction between main and restricted is done based on licensing:
software in main fulfils the necessary freedoms for modification and
redistribution, software in restricted may not.

It is simple to pick a component for the software, you simply read the
licence.  It also makes sense for the components to be separate since it
allows users (and derivatives) to make a decision not to accept software
under restricted licence conditions.


The distinction between main and universe is instead done based on
"support".  But what does this actually mean?

Canonical provides commercial support for all packages in main.  Well,
that's not actually true: we don't provide commercial support for them
all.

More than that, this needlessly emphasises Canonical in the Ubuntu
community.  Why can't another company or group provide support?  Why
doesn't members of MOTU supporting the package mean it can move to main?

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.

Security support is another angle to take; and another bucket of worms.


So the distinction is actually quite blurry.  Perhaps the separation
still makes sense for user choice?  I don't this is true either.

We used to have only main and restricted enabled by default, users had
to deliberately enable universe to get the software from it.  Some time
ago we changed this to instead be handled through the user interface,
declaring whether or not you'd receive this strange "support" for the
package or not.


And this still doesn't cover the fact that in just a few months time,
there will be a LOT of packages in the "main" component of a "supported"
release (dapper) that won't be "supported" anymore.


I therefore propose an alternative.

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.

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.

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.


What about upload privileges?

Let's do those the same way.

Teams can approach the Technical Board for permission to own a
particular seed; if granted, their team has permission to upload any
package in the resulting list of packages from that seed.

(The seed system already has priorities, so you couldn't add a package
 in ubuntu-desktop and take it over; at least, not without negotiation.)

The kubuntu-dev team could maintain (and support, etc.) Kubuntu.
xubuntu-dev could do the same for Xubuntu, and so on.  To become an
uploader for Kubuntu, you would need to be granted permission from that
team, not from the Technical Board.

That team is better placed to judge your skills anyway.

We'd still need the existing two teams:

ubuntu-core-dev would have permission to upload to everything.  It would
remain the ultimate accolade technical team, and membership would be
available to anyone who has excelled in

ubuntu-dev, which would have permission to upload to anything not
seeded, and would be members of most of the other technical teams as
well.  This is where you would graduate to after being a member of a
specific team.


Like I said, it's a straw man.  Please debate, discuss, argue, but don't
flame :-)

Scott
-- 
Scott James Remnant
scott at ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20071212/dc351a16/attachment.pgp