| 1 |
On Wed, 2006-03-22 at 22:03 +0000, Stuart Herbert wrote: |
| 2 |
> I'd like to offer two wiki engines and two version control systems on |
| 3 |
> overlays.g.o. I believe that gives us enough choice without us |
| 4 |
> loading the box with too much software for us to keep on top of. |
| 5 |
> |
| 6 |
> One thing that was never planned was any form of shell access to this |
| 7 |
> box, except for the team creating/destroying overlays. It looks like |
| 8 |
> this will be necessary to support a distributed vcs. I'll talk to |
| 9 |
> infra and see what we could do about providing some form of ssh access |
| 10 |
> to help us support a distributed vcs. |
| 11 |
> |
| 12 |
> Trac and SVN would be my first choice. MoinMoin would be my |
| 13 |
> recommendation for the second wiki engine. What should the second |
| 14 |
> version control system be? I don't use them, I have no experience |
| 15 |
> with them, and so I have no preference of what this should be. |
| 16 |
> |
| 17 |
> To answer Daniel's question about "official" ... the overlays hosted |
| 18 |
> on overlays.g.o would be "official". The "overlays" project will be |
| 19 |
> accountable for overlays.g.o overall. It would make sense for the |
| 20 |
> "overlays" project to be a sub-project of infra. |
| 21 |
> |
| 22 |
> To ensure "officialness" and (what I personally care more about) |
| 23 |
> accountability, project overlays will be created for projects that |
| 24 |
> meet the description of a project in the metastructure [1]. The |
| 25 |
> overlays team will have to be strict on this, to ensure |
| 26 |
> "officialness". The overlay must be requested by one of the leads of |
| 27 |
> the project. The lead(s) would be jointly accountable for the overlay |
| 28 |
> and all its contents. Leads will be able to ask for commit / wiki |
| 29 |
> edit access for non-devs. |
| 30 |
> |
| 31 |
> Developer overlays would only be created for active Gentoo developers, |
| 32 |
> and they would be accountable for its contents. Non-developers will |
| 33 |
> not be given write access to developer overlays. |
| 34 |
> |
| 35 |
> By default - working on the same principle of trust that governs all |
| 36 |
> developers w.r.t. the Portage tree - all developers will be able to |
| 37 |
> commit to all overlays. If we can't trust you to respect other |
| 38 |
> people's overlays, then we can't trust you with commit access to the |
| 39 |
> Portage tree, and you're not fit to be a Gentoo dev in the first place |
| 40 |
> :P The only "restriction" will be that you'll need to ask the overlay |
| 41 |
> project team to setup your access the very first time. |
| 42 |
> |
| 43 |
> Anyone wanting a "secret" overlay needs to make their own hosting arrangements. |
| 44 |
> |
| 45 |
> To answer Daniel's other question, about bugs.g.o ... trac on |
| 46 |
> overlays.g.o will have its bug tracking system disabled. We already |
| 47 |
> have one bug tracking system - bugs.g.o - and that's sufficient. |
| 48 |
> |
| 49 |
> [1] http://www.gentoo.org/proj/en/glep/glep-0039.html |
| 50 |
|
| 51 |
Hi Stuart |
| 52 |
|
| 53 |
I agree with the wiki because it seems to be an easy way to users and |
| 54 |
developers comunicate together and work. Like i said a few months ago |
| 55 |
the documentation won't give any problems to GDP since GDP provides high |
| 56 |
level docs. The wiki will also help our projects since it can be added |
| 57 |
TODO's, roadmaps and all that stuff. About the overlay the best way imo |
| 58 |
is provide a unique overlay with external contribs maintained by users |
| 59 |
and devs (of course commit rights only for devs.). |
| 60 |
|
| 61 |
-- |
| 62 |
Luis Medinas <metalgod@g.o> |
| 63 |
http://dev.gentoo.org/~metalgod |
| 64 |
Gentoo Linux Developer: AMD64,Printing,Media-Optical,Sound |
| 65 |
|
| 66 |
-- |
| 67 |
gentoo-dev@g.o mailing list |
Archives