Re: [gentoo-dev] Sandboxes

[Chris Gianelloni <wolf31o2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

On Thu, 2006-03-23 at 18:45 -0500, Alec Warner wrote:
> PROPOSAL:
> 
> a) overlays.gentoo.org -> A sub-domain for hosting overlays or
> 'development sandboxes'.  Developers want an area for sandboxed
> development of packages outside of the main tree.  As stated in the
> previous thread this allows faster developer with less overread (QA,
> changelogs, etc..).  These sandboxed areas also allow non-developers to
> contribute to projects in a useful manner.
> 
> b) overlays.gentoo.org -> Is not meant for public consumption by users.
>  overlays.gentoo.org is merely a development aid and not meant for
> public consumption.  Users tend to not know how overlays are
> implemented.  Multiple activated overlays also can cause hard to debug
> issues as overlays over-ride ebuilds and eclass in each other and the
> tree itself.
> 
> c) Overlays may be secured on an per-overlay basis to prevent normal
> users from both reading and writing to the overlay.  For example a
> project may wish to have an overlay and invite two or three
> non-developers to contribute.  This makes creating small development
> units easy, while keeping QA the main tree relatively high.
> 
> This is what I see, and this is kinda what I would want.  As an overlay
> "creator" I should be able to add/remove accounts from my own overlay (
> to reduce the load on the overlay project/infra ).  In essence, creating
> a bunch of small communities for development.
> 
> Thoughts on ideas on this somewhat more focussed idea? ( or at least I
> think it's more focused :P )

OK.

I have an idea for a compromise, then.

An overlay, when created is not readable by anyone without an account.
The new overlay is governed by whatever rules that the overlay owners
wish to use.  However, before an overlay can be opened up for public RO
access, one simple rule must be followed:  It must not break the normal
tree through its use.  What this means is if you've got some whiz-bang
version of foo out that that requires changes to bar.eclass, then
bar.eclass (in your overlay) needs to remain backwards compatible with
what is in the tree insofar as it does not break non-overlay ebuilds
through its use.

With this *single* policy, we manage to reduce the problems that have
been brought up in the other threads.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]