Strawman: merge main and universe

[Scott James Remnant]

On Thu, 2007-12-13 at 07:52 +0900, Emmet Hikory wrote:

> Seeds make a lot of sense in this case, and also saves the issues
> with MainInclusionReports: those with access to the seed are able to
> adjust the content of the seed, following the guidelines for a given
> seed.
> 
I think we'd probably still have something very much like those.  An MIR
right now is permission to add your package to one of the seeds (which
determine the set of packages in main).

With my strawman model, you'd still need some kind of permission to
change a seed, so the MIR still fits.  The seeds still determine who
supports and who can upload to the packages, as they do now.  It's just
finer grained and gives precise answers.

(The difference being that the seed owners may set their own
permissions; the primary seeds that currently determine what goes in
main would probably keep the same work flow as they do today, the only
difference being that the archive admins don't need to change a
component after committing the seed change).

> A given seed may contain packages that are also in other seeds
> 
Ah, I perhaps assumed a little too much knowledge of the seed system.  I
suggest people read https://wiki.ubuntu.com/SeedManagement for more
details.

This is already handled in the seed model.  Seeds are built and based on
other seeds, and have inherent priorities.

If a package seeded in the standard seed is also seeded in the desktop
seed, then it only appears in the standard package list -- since
standard trumps it.  Likewise for dependencies, if a seeded package in
standard depends on a package seeded in desktop, it's actually promoted
to standard.  You see output like the following from germinate:

! Promoted dmidecode from standard to minimal to satisfy laptop-detect

So since the core packages like udev are seeded in a higher priority
seed like standard, then those packages are owned by their owning team
(core-dev) not by the final derivatives.

This means that making a new derivative is as simple as creating a seed
and deciding where it derives from; desktop or standard most likely.
You then get upload rights to the packages unique to your set, where you
have overlap, the higher priority seed wins (which may simply be the
first alphabetically) -- at that point rights have to be negotiated, and
the TB can step in and help (probably by suggesting a common base seed).

> As the number of seeded sets grows, the set of packages managed by
> ~ubuntu-dev shrinks
> 
This is covered in the straw man.  ubuntu-dev would be a member of the
individual teams like kubuntu-dev, xubuntu-dev.

This means there's only ever one team in charge of a particular package.
Picking on some examples:

epiphany is part of the gobuntu seed
gobuntu is owned by gobuntu-dev
thus epiphany can be uploaded by gobuntu-dev

ubuntu-dev is a member of gobuntu-dev by policy

ubuntu-core-dev is a member of ubuntu-dev
thus epiphany can be uploaded by ubuntu-core-dev

motu is a member of ubuntu-dev
thus epiphany can be uploaded by motu

People that can upload epiphany: gobuntu-dev, ubuntu-core-dev, motu


udev is part of the minimal seed
minimal is owned by ubuntu-core-dev
thus udev can be uploaded by ubuntu-core-dev

People that can upload udev: ubuntu-core-dev


doomtetris is not seeded
not seeded packages are owned by ubuntu-dev

ubuntu-core-dev is a member of ubuntu-dev
thus doomtetris can be uploaded by ubuntu-core-dev

motu is a member of ubuntu-dev
thus doomtetris can be uploaded by motu

People that can upload epiphany: ubuntu-core-dev, motu


So MOTU would have the rough privilege it has today; it's package set
may actually increase a little bit in fact as the "fight to get into
main" has gone away and we're all sharing a single component.

The primary change is that teams like kubuntu, MOTU Science, etc. can
exist with actual upload rights of their own and nurture their own
developers; and those developers can graduate to MOTU proper, and then
eventually to ubuntu-core-dev.

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/20071213/f9649c92/attachment.pgp