1 |
Hi Stuart, |
2 |
|
3 |
I'd like to comment on some of your plans for overlays.g.o. |
4 |
|
5 |
Am Mittwoch, 22. März 2006 23:03 schrieb Stuart Herbert: |
6 |
> It's probably the right time for me to flesh out what I've been |
7 |
> planning for overlays.g.o. |
8 |
> |
9 |
> The vision I have for overlays.g.o is one official home for all Gentoo |
10 |
> overlays run by projects and by individual Gentoo devs. I see the |
11 |
Also for Arch/Herd Testers? |
12 |
|
13 |
> homepage itself running Planet (just like planet.g.o), using the RSS |
14 |
> feeds from the overlays to display the changelogs from all the |
15 |
> overlays. The links down the left hand side of the page go to the |
16 |
> homepage for each of the overlays. The homepages are separate wiki |
17 |
> instances. |
18 |
Well, there is a couple of Gentoo devs who are not particularly comfortable |
19 |
with wikis (including myself). Why change things the way they are currently? |
20 |
I'd suggest to use one repository per project and to add a 'website' or 'site' |
21 |
directory. In this case we could use the good ol' GuideXML/SCM combination. |
22 |
> |
23 |
> http://overlays.g.o/proj/<project-name>/ for overlays run by herds |
24 |
> listed in herds.xml |
25 |
> http://overlays.g.o/svn/<project-name>/ for the SVN repos |
26 |
> |
27 |
> and |
28 |
Like above: use http://o.g.o/proj/<project-name>/ for the information content |
29 |
and http://o.g.o/proj/<project-name>/svn/ for the overlay. |
30 |
|
31 |
> http://overlays.g.o/dev/<developer>/ for overlays run by individual |
32 |
> developers http://overlays.g.o/svn/<developer>/ for the SVN repos |
33 |
same as above :-) |
34 |
|
35 |
> There's a practical limit to the amount of software we can support on |
36 |
> overlays.g.o. The less we install, the less the overhead of |
37 |
> administrating this system for infra and the overlays admin team (I'm |
38 |
> looking for responsible volunteers to join that team, if you're |
39 |
> interested). |
40 |
Another reason for dropping the wiki |
41 |
> |
42 |
> I'd like to offer two wiki engines and two version control systems on |
43 |
> overlays.g.o. I believe that gives us enough choice without us |
44 |
> loading the box with too much software for us to keep on top of. |
45 |
In case we use wiki, why _two_ wiki engines? |
46 |
|
47 |
> To answer Daniel's question about "official" ... the overlays hosted |
48 |
> on overlays.g.o would be "official". The "overlays" project will be |
49 |
> accountable for overlays.g.o overall. It would make sense for the |
50 |
> "overlays" project to be a sub-project of infra. |
51 |
|
52 |
> To ensure "officialness" and (what I personally care more about) |
53 |
> accountability, project overlays will be created for projects that |
54 |
> meet the description of a project in the metastructure [1]. The |
55 |
> overlays team will have to be strict on this, to ensure |
56 |
> "officialness". The overlay must be requested by one of the leads of |
57 |
> the project. The lead(s) would be jointly accountable for the overlay |
58 |
> and all its contents. Leads will be able to ask for commit / wiki |
59 |
> edit access for non-devs. |
60 |
Please consider also to let QA and Security have commit access to all overlays |
61 |
(If they're so inclined). |
62 |
|
63 |
> Developer overlays would only be created for active Gentoo developers, |
64 |
> and they would be accountable for its contents. Non-developers will |
65 |
> not be given write access to developer overlays. |
66 |
|
67 |
> By default - working on the same principle of trust that governs all |
68 |
> developers w.r.t. the Portage tree - all developers will be able to |
69 |
> commit to all overlays. If we can't trust you to respect other |
70 |
> people's overlays, then we can't trust you with commit access to the |
71 |
> Portage tree, and you're not fit to be a Gentoo dev in the first place |
72 |
I would say this should be clarified some more. Surely anybody with an access |
73 |
to an overlay can commit, but the projects should be the keepers of the keys. |
74 |
Overlays are not the tree, they are probably very experimental. I could |
75 |
imagine that i wouldn't want anyone to modify say an experimental gcc ebuild |
76 |
from toolchain's overlay for example. |
77 |
|
78 |
Stuart: Overall, i like your proposal. I would suggest to turn it into a GLEP |
79 |
and I'm willing to help you with this. |
80 |
|
81 |
Danny |
82 |
-- |
83 |
Danny van Dyk <kugelfang@g.o> |
84 |
Gentoo/AMD64 Project, Gentoo Scientific Project |
85 |
|
86 |
-- |
87 |
gentoo-dev@g.o mailing list |