| 1 |
On Thu, 2006-03-23 at 18:45 -0500, Alec Warner wrote: |
| 2 |
> PROPOSAL: |
| 3 |
> |
| 4 |
> a) overlays.gentoo.org -> A sub-domain for hosting overlays or |
| 5 |
> 'development sandboxes'. Developers want an area for sandboxed |
| 6 |
> development of packages outside of the main tree. As stated in the |
| 7 |
> previous thread this allows faster developer with less overread (QA, |
| 8 |
> changelogs, etc..). These sandboxed areas also allow non-developers to |
| 9 |
> contribute to projects in a useful manner. |
| 10 |
> |
| 11 |
> b) overlays.gentoo.org -> Is not meant for public consumption by users. |
| 12 |
> overlays.gentoo.org is merely a development aid and not meant for |
| 13 |
> public consumption. Users tend to not know how overlays are |
| 14 |
> implemented. Multiple activated overlays also can cause hard to debug |
| 15 |
> issues as overlays over-ride ebuilds and eclass in each other and the |
| 16 |
> tree itself. |
| 17 |
> |
| 18 |
> c) Overlays may be secured on an per-overlay basis to prevent normal |
| 19 |
> users from both reading and writing to the overlay. For example a |
| 20 |
> project may wish to have an overlay and invite two or three |
| 21 |
> non-developers to contribute. This makes creating small development |
| 22 |
> units easy, while keeping QA the main tree relatively high. |
| 23 |
> |
| 24 |
> This is what I see, and this is kinda what I would want. As an overlay |
| 25 |
> "creator" I should be able to add/remove accounts from my own overlay ( |
| 26 |
> to reduce the load on the overlay project/infra ). In essence, creating |
| 27 |
> a bunch of small communities for development. |
| 28 |
> |
| 29 |
> Thoughts on ideas on this somewhat more focussed idea? ( or at least I |
| 30 |
> think it's more focused :P ) |
| 31 |
|
| 32 |
OK. |
| 33 |
|
| 34 |
I have an idea for a compromise, then. |
| 35 |
|
| 36 |
An overlay, when created is not readable by anyone without an account. |
| 37 |
The new overlay is governed by whatever rules that the overlay owners |
| 38 |
wish to use. However, before an overlay can be opened up for public RO |
| 39 |
access, one simple rule must be followed: It must not break the normal |
| 40 |
tree through its use. What this means is if you've got some whiz-bang |
| 41 |
version of foo out that that requires changes to bar.eclass, then |
| 42 |
bar.eclass (in your overlay) needs to remain backwards compatible with |
| 43 |
what is in the tree insofar as it does not break non-overlay ebuilds |
| 44 |
through its use. |
| 45 |
|
| 46 |
With this *single* policy, we manage to reduce the problems that have |
| 47 |
been brought up in the other threads. |
| 48 |
|
| 49 |
-- |
| 50 |
Chris Gianelloni |
| 51 |
Release Engineering - Strategic Lead |
| 52 |
x86 Architecture Team |
| 53 |
Games - Developer |
| 54 |
Gentoo Linux |
Archives