1 |
Hi Danny, |
2 |
|
3 |
On 3/23/06, Danny van Dyk <kugelfang@g.o> wrote: |
4 |
> Hi Stuart, |
5 |
> |
6 |
> I'd like to comment on some of your plans for overlays.g.o. |
7 |
|
8 |
:) |
9 |
|
10 |
> > The vision I have for overlays.g.o is one official home for all Gentoo |
11 |
> > overlays run by projects and by individual Gentoo devs. I see the |
12 |
> Also for Arch/Herd Testers? |
13 |
|
14 |
Sure. |
15 |
|
16 |
> Well, there is a couple of Gentoo devs who are not particularly comfortable |
17 |
> with wikis (including myself). Why change things the way they are currently? |
18 |
|
19 |
Because previous threads here on -dev asking for a wiki prove that not |
20 |
everyone is comfortable / happy with how things currently are ... |
21 |
myself included. |
22 |
|
23 |
Wikis are a much lower barrier to entry than GuideXML ... and they |
24 |
have advantages over GuideXML. |
25 |
|
26 |
There's no reason why you can't create GuideXML and store / publish it |
27 |
via the overlay, even if there is a wiki. We do that with the PHP |
28 |
overlay. |
29 |
|
30 |
> I'd suggest to use one repository per project and to add a 'website' or 'site' |
31 |
> directory. In this case we could use the good ol' GuideXML/SCM combination. |
32 |
|
33 |
That's easy enough. We can establish a 'known location' in the VCS |
34 |
tree where GuideXML will be stored, and run a simple cron script to |
35 |
extract it and put it into the website directory for public viewing. |
36 |
|
37 |
Or you could just publish it on www.g.o/proj/en/<project>/ instead :) |
38 |
|
39 |
> Like above: use http://o.g.o/proj/<project-name>/ for the information content |
40 |
> and http://o.g.o/proj/<project-name>/svn/ for the overlay. |
41 |
|
42 |
Could do. I always preferred separate paths to ensure no clash with |
43 |
any other content under /proj/<project-name>/. |
44 |
|
45 |
> Another reason for dropping the wiki |
46 |
|
47 |
No. We can make the wiki optional, but not offering a wiki at all |
48 |
makes it impossible for existing successful, externally hosted |
49 |
overlays to move to overlays.g.o. |
50 |
|
51 |
> In case we use wiki, why _two_ wiki engines? |
52 |
|
53 |
Because different people have different preferences, and I don't |
54 |
believe in 'one size fits all'. Adding a little bit of flexibility in |
55 |
the right places will make o.g.o more successful. |
56 |
|
57 |
> Please consider also to let QA and Security have commit access to all overlays |
58 |
> (If they're so inclined). |
59 |
|
60 |
That's already covered under the principle that QA and Security are |
61 |
staffed by devs. |
62 |
|
63 |
> I would say this should be clarified some more. Surely anybody with an access |
64 |
> to an overlay can commit, but the projects should be the keepers of the keys. |
65 |
> Overlays are not the tree, they are probably very experimental. I could |
66 |
> imagine that i wouldn't want anyone to modify say an experimental gcc ebuild |
67 |
> from toolchain's overlay for example. |
68 |
|
69 |
I want to operate the overlays on the same principles that we use to |
70 |
manage the Portage tree. We tell developers that they have to respect |
71 |
other people's packages, and can't go around changing what they feel |
72 |
like. The same should hold true for the overlays. |
73 |
|
74 |
> Stuart: Overall, i like your proposal. I would suggest to turn it into a GLEP |
75 |
> and I'm willing to help you with this. |
76 |
|
77 |
I already have Infra's agreement and active support to deliver this (I |
78 |
can't thank Lance and Kurt enough for their help to date on this). |
79 |
It's a new service - one that no-one is required to use (although I |
80 |
ferverently hope that it proves very popular). I don't believe that |
81 |
it needs a GLEP. |
82 |
|
83 |
What it does need is a successful overlay project team, to administer |
84 |
the service and help it evolve over the coming years. |
85 |
|
86 |
Best regards, |
87 |
Stu |
88 |
-- |
89 |
|
90 |
-- |
91 |
gentoo-dev@g.o mailing list |