| 1 |
To hijack the overlay thread, I see a few things here: |
| 2 |
|
| 3 |
MOTIVATION: |
| 4 |
|
| 5 |
a) Developers don't like putting experimental stuff in the tree: This is |
| 6 |
usually because Joe Ricer picks up the ebuild, 'tests' it, it breaks and |
| 7 |
he files a bug. Joe Ricer has no clue what went wrong or what he is |
| 8 |
doing and said Developer gets annoyed as hell by Joe Ricer's lack of |
| 9 |
knowledge/co-operation with regards to bug report. For more popular |
| 10 |
packages, multiply Joe Ricer by some random two digit number. |
| 11 |
|
| 12 |
b) Developers want users to contribute too: Users don't have commit |
| 13 |
access to the main tree (for good reason, as stated in the other |
| 14 |
thread). However developers would like users to be able to contribute |
| 15 |
in some meaningful way to a project/package without the red tape that is |
| 16 |
bugzilla. |
| 17 |
|
| 18 |
PROPOSAL: |
| 19 |
|
| 20 |
a) overlays.gentoo.org -> A sub-domain for hosting overlays or |
| 21 |
'development sandboxes'. Developers want an area for sandboxed |
| 22 |
development of packages outside of the main tree. As stated in the |
| 23 |
previous thread this allows faster developer with less overread (QA, |
| 24 |
changelogs, etc..). These sandboxed areas also allow non-developers to |
| 25 |
contribute to projects in a useful manner. |
| 26 |
|
| 27 |
b) overlays.gentoo.org -> Is not meant for public consumption by users. |
| 28 |
overlays.gentoo.org is merely a development aid and not meant for |
| 29 |
public consumption. Users tend to not know how overlays are |
| 30 |
implemented. Multiple activated overlays also can cause hard to debug |
| 31 |
issues as overlays over-ride ebuilds and eclass in each other and the |
| 32 |
tree itself. |
| 33 |
|
| 34 |
c) Overlays may be secured on an per-overlay basis to prevent normal |
| 35 |
users from both reading and writing to the overlay. For example a |
| 36 |
project may wish to have an overlay and invite two or three |
| 37 |
non-developers to contribute. This makes creating small development |
| 38 |
units easy, while keeping QA the main tree relatively high. |
| 39 |
|
| 40 |
This is what I see, and this is kinda what I would want. As an overlay |
| 41 |
"creator" I should be able to add/remove accounts from my own overlay ( |
| 42 |
to reduce the load on the overlay project/infra ). In essence, creating |
| 43 |
a bunch of small communities for development. |
| 44 |
|
| 45 |
Thoughts on ideas on this somewhat more focussed idea? ( or at least I |
| 46 |
think it's more focused :P ) |
| 47 |
|
| 48 |
-Alec Warner |
| 49 |
-- |
| 50 |
gentoo-dev@g.o mailing list |
Archives