Strawman: merge main and universe

[Emmet Hikory]

On Dec 13, 2007 9:18 AM, Scott James Remnant wrote:
> 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).

    Yes.  This seemed to be the primary advantage: a given team would
be able to process the changes directly (by whichever is their
preferred workflow) without requiring intervention of the archive
administrators, which significantly reduces the pain of moving things
in and out of seeds.  For Ubuntu-desktop related seeds, the workflow
would likely stay the same, but other teams may select other
workflows, and the archive-admins do not have extra work due to the
addition of more teams.

> > 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.

    I've just read through that page, and looked at some seeds.  That
structure seems to be in place for minimal, standard, desktop, etc.
On the other hand, it doesn't currently appear to be in place for
mythbuntu or ubuntustudio.  Maybe this is just documentation, or would
need to be part of a transition plan.

    Alternately, I'd wonder how this would work for things like
Xubuntu, where many of the packages to be seeded would also be part of
desktop.  Would desktop take priority?  Who decides which seed takes
precedence in cases of sharing?  Would this result in the definition
of new seeds for shared areas of interest?

> > 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.

    Excellent.  My misinterpretation.  This addresses my concerns
about splintering the repositories and sponsoring.

> 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.

    It actually sounds like it significantly simplifies workflow for
MOTU, as there would no longer be a need to balance the advantages of
pushing to main with the inconvenience of losing upload rights as a
result, and individuals with interest in specific areas traditionally
in main would be able to join that team without needing to be a member
of core-dev directly.

> 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.

     Phrased that way, it seems to actually improve the options
available for recruitment and sponsoring, rather than interfere.  I'm
not sure that all new developers should "graduate" to MOTU if their
primary interest is team-specific: I can well imagine a developer
actively working on Ubuntu desktop who is not a member of MOTU (and
thereby ~ubuntu-dev), yet whose work is unimpeded by this.  On the
other hand, with such a group-managed repository, it may make sense
for first being MOTU to become a requirement for gaining core-dev, as
a means of demonstrating restraint when granted access to packages not
specific to areas of interest.

-- 
Emmet HIKORY