Re: [gentoo-dev] Official overlay support

[Stuart Herbert]

> This definitely sounds like a fun idea. It would be even cooler if we
> were using a distributed SCM on both ends that allowed for easy merging.
>
> Donnie

It's probably the right time for me to flesh out what I've been
planning for overlays.g.o.

The vision I have for overlays.g.o is one official home for all Gentoo
overlays run by projects and by individual Gentoo devs.  I see the
homepage itself running Planet (just like planet.g.o), using the RSS
feeds from the overlays to display the changelogs from all the
overlays.  The links down the left hand side of the page go to the
homepage for each of the overlays.  The homepages are separate wiki
instances.

  http://overlays.g.o/proj/<project-name>/ for overlays run by herds
listed in herds.xml
  http://overlays.g.o/svn/<project-name>/ for the SVN repos

and

  http://overlays.g.o/dev/<developer>/ for overlays run by individual developers
  http://overlays.g.o/svn/<developer>/ for the SVN repos

There's a practical limit to the amount of software we can support on
overlays.g.o.  The less we install, the less the overhead of
administrating this system for infra and the overlays admin team (I'm
looking for responsible volunteers to join that team, if you're
interested).

I'd like to offer two wiki engines and two version control systems on
overlays.g.o.  I believe that gives us enough choice without us
loading the box with too much software for us to keep on top of.

One thing that was never planned was any form of shell access to this
box, except for the team creating/destroying overlays.  It looks like
this will be necessary to support a distributed vcs.  I'll talk to
infra and see what we could do about providing some form of ssh access
to help us support a distributed vcs.

Trac and SVN would be my first choice.  MoinMoin would be my
recommendation for the second wiki engine.  What should the second
version control system be?  I don't use them, I have no experience
with them, and so I have no preference of what this should be.

To answer Daniel's question about "official" ... the overlays hosted
on overlays.g.o would be "official".  The "overlays" project will be
accountable for overlays.g.o overall.  It would make sense for the
"overlays" project to be a sub-project of infra.

To ensure "officialness" and (what I personally care more about)
accountability, project overlays will be created for projects that
meet the description of a project in the metastructure [1].  The
overlays team will have to be strict on this, to ensure
"officialness".  The overlay must be requested by one of the leads of
the project.  The lead(s) would be jointly accountable for the overlay
and all its contents.  Leads will be able to ask for commit / wiki
edit access for non-devs.

Developer overlays would only be created for active Gentoo developers,
and they would be accountable for its contents.  Non-developers will
not be given write access to developer overlays.

By default - working on the same principle of trust that governs all
developers w.r.t. the Portage tree - all developers will be able to
commit to all overlays.  If we can't trust you to respect other
people's overlays, then we can't trust you with commit access to the
Portage tree, and you're not fit to be a Gentoo dev in the first place
:P  The only "restriction" will be that you'll need to ask the overlay
project team to setup your access the very first time.

Anyone wanting a "secret" overlay needs to make their own hosting arrangements.

To answer Daniel's other question, about bugs.g.o ... trac on
overlays.g.o will have its bug tracking system disabled.  We already
have one bug tracking system - bugs.g.o - and that's sufficient.

[1] http://www.gentoo.org/proj/en/glep/glep-0039.html

Best regards,
Stu

-- 
gentoo-dev@g.o mailing list