You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by Pier Fumagalli <pi...@betaversion.org> on 2003/03/24 20:19:16 UTC
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS
module
On 24/3/03 9:13 am, "Jeff Turner" <je...@apache.org> wrote:
> On Mon, Mar 24, 2003 at 07:31:39AM +0100, Steven Noels wrote:
>> In order to get one little step closer to the 'new' document
>> infrastructure, many of us seek clarity whether we should move docs to a
>> separate CVS module or not. The benefits and downfalls are largely
>> known, so let's vote on this and get this issue cleared.
>>
>> My own personal bias: don't forget the different Cocoon _versions_ are
>> now stored in separate modules, too.
>>
>> Please cast your vote:
>>
> [ ] creation of cocoon-docs module
> [+1] docs should stay in src/documentation of the code tree module(s)
>
> Because:
>
> - With a separate cocoon-docs module, I don't see how the various
> code-related files (status.xml, jars.xml) are obtained.
>
> - Making a separate doc module kills outright any future efforts to
> generate docs directly from code (e.g. a component manual).
>
> - I think that by default, doc changes should only apply to one codebase
> (2.0 or 2.1). There are many differences that are *meant* to be there,
> that could get lost if 2.0 and 2.1 docs are generated from a common
> source.
Folks, do you know that there's the possibility to alias certain subparts of
a particular CVS repository from another repository?
Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
Apache does it already with its httpd-docs repository, aliased to
httpd-2.0/docs (or something like it)...
Pier
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Mercredi, 26 mars 2003, à 10:45 Europe/Zurich, Stefano Mazzocchi a
écrit :
> ....So, the proposal is not about forcing docu-oriented people as
> second-class citizens, but potentially allowing people (or services)
> that *request* or *need* to be docu-oriented-only to be able to be
> given karma like that...
Sounds good - a cocoon-docs CVS which is an alias to the "docs"
subdirectory of the current CVS offers what we need IMHO (judging from
the recent messages here an on cocoon-docs).
Also, I assume the alias would be moved when a new version is released,
so as to automatically freeze the current release's docs with the code
while still allowing them to be corrected later on if needed.
This would be transparent from the point of view of the cocoon-docs
repository, which is also an advantage if you're thinking CMS / webdav
access or whatever.
I'm +1 on this "cocoon-docs alias repository" thing.
-Bertrand
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
Posted by Stefano Mazzocchi <st...@apache.org>.
David Crossley wrote:
> Stefano Mazzocchi wrote:
>
>>Pier Fumagalli wrote:
>
> <snip/>
>
>>>Folks, do you know that there's the possibility to alias certain subparts of
>>>a particular CVS repository from another repository?
>>>
>>>Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
>>>
>>>Apache does it already with its httpd-docs repository, aliased to
>>>httpd-2.0/docs (or something like it)...
>>
>>Uh, that sounds *AWESOME*!
>>
>>Could it be possible, then, to restrict access of some committers only
>>to the doc module but have commits coming thru the *main* module land in
>>there as well?
>>
>>That would solve all issues at once, I guess.
>>
>>Stefano.
>
>
> Hold on. In another thread (not sure when/what) we decided that
> there would be no distinction about cocoon committers. They are
> committers for the whole of code and docs and would have access
> to the whole cvs.
>
> Your proposal is going against your earlier valid point that
> we ensure there is no "perception that documents are maintained
> by somebody else".
Wait. What I'm thinking is the chance of being able to use a dummy CVS
user for a potential CMS that uses CVS as its document repository (won't
provide fast xpath queries (well, we could index it side-by-side with
xindice anyway, but will provide metadata and versioning).
The infrastructure teams *does* *not* like service-attached accounts for
icarus/daedalus and this is to prevent the introduction of weaker
security points than SSH to the workflow.
at the same time, we have community oversight over all changes, so even
if somebody routes around security restrictions of our CMS and commits
straight to the CVS bypassing all SSH security (becasue the CMS holds
the private key of that dummy CMS account), he/she will simply write
something on our docs, we'll get a commit email and we'll fix it and
since publishing is manually driven, this won't never end up on the web
site.
this is, IMO, a very safe architecture even if our CMS is exploited and
its security bypassed.
but if we allow the CMS to work on the *entire* CVS repository (thus
being able to touch code), I can predict that infrastructure will feel
much more uneasy.
So, the proposal is not about forcing docu-oriented people as
second-class citizens, but potentially allowing people (or services)
that *request* or *need* to be docu-oriented-only to be able to be given
karma like that.
Stefano.
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS
module
Posted by David Crossley <cr...@indexgeo.com.au>.
Stefano Mazzocchi wrote:
> Pier Fumagalli wrote:
<snip/>
> >
> > Folks, do you know that there's the possibility to alias certain subparts of
> > a particular CVS repository from another repository?
> >
> > Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
> >
> > Apache does it already with its httpd-docs repository, aliased to
> > httpd-2.0/docs (or something like it)...
>
> Uh, that sounds *AWESOME*!
>
> Could it be possible, then, to restrict access of some committers only
> to the doc module but have commits coming thru the *main* module land in
> there as well?
>
> That would solve all issues at once, I guess.
>
> Stefano.
Hold on. In another thread (not sure when/what) we decided that
there would be no distinction about cocoon committers. They are
committers for the whole of code and docs and would have access
to the whole cvs.
Your proposal is going against your earlier valid point that
we ensure there is no "perception that documents are maintained
by somebody else".
--David
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS
module
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 25/3/03 9:14 am, "Stefano Mazzocchi" <st...@apache.org> wrote:
> Pier Fumagalli wrote:
>>
>> Folks, do you know that there's the possibility to alias certain subparts of
>> a particular CVS repository from another repository?
>>
>> Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
>>
>> Apache does it already with its httpd-docs repository, aliased to
>> httpd-2.0/docs (or something like it)...
>
> Uh, that sounds *AWESOME*!
>
> Could it be possible, then, to restrict access of some committers only
> to the doc module but have commits coming thru the *main* module land in
> there as well?
In theory yes... We can play around with Karma for directories as well...
> That would solve all issues at once, I guess.
If you say so! :-) I'm going to try it out on my repo at work, and will tell
you what/how can be done exactly...
Pier
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> On 24/3/03 9:13 am, "Jeff Turner" <je...@apache.org> wrote:
>
>
>>On Mon, Mar 24, 2003 at 07:31:39AM +0100, Steven Noels wrote:
>>
>>>In order to get one little step closer to the 'new' document
>>>infrastructure, many of us seek clarity whether we should move docs to a
>>>separate CVS module or not. The benefits and downfalls are largely
>>>known, so let's vote on this and get this issue cleared.
>>>
>>>My own personal bias: don't forget the different Cocoon _versions_ are
>>>now stored in separate modules, too.
>>>
>>>Please cast your vote:
>>>
>>
>>[ ] creation of cocoon-docs module
>>[+1] docs should stay in src/documentation of the code tree module(s)
>>
>>Because:
>>
>>- With a separate cocoon-docs module, I don't see how the various
>>code-related files (status.xml, jars.xml) are obtained.
>>
>>- Making a separate doc module kills outright any future efforts to
>>generate docs directly from code (e.g. a component manual).
>>
>>- I think that by default, doc changes should only apply to one codebase
>>(2.0 or 2.1). There are many differences that are *meant* to be there,
>>that could get lost if 2.0 and 2.1 docs are generated from a common
>>source.
>
>
> Folks, do you know that there's the possibility to alias certain subparts of
> a particular CVS repository from another repository?
>
> Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
>
> Apache does it already with its httpd-docs repository, aliased to
> httpd-2.0/docs (or something like it)...
Uh, that sounds *AWESOME*!
Could it be possible, then, to restrict access of some committers only
to the doc module but have commits coming thru the *main* module land in
there as well?
That would solve all issues at once, I guess.
Stefano.
Re: [vote] micro-decision for docs: creation of cocoon-docs CVS
module
Posted by Andrew Savory <an...@luminas.co.uk>.
On Mon, 24 Mar 2003, Pier Fumagalli wrote:
> Folks, do you know that there's the possibility to alias certain subparts of
> a particular CVS repository from another repository?
>
> Like "cocoon-2.1/src/docs" can be stored in the "cocoon-docs" repository.
>
> Apache does it already with its httpd-docs repository, aliased to
> httpd-2.0/docs (or something like it)...
This still leaves us with the problem of the docs being kept within one
codebase (eg 2.1) though, which would be wrong if we're updating them for
a 2.2 repository.
Useful to know, though ...
Andrew.
--
Andrew Savory Email: andrew@luminas.co.uk
Managing Director Tel: +44 (0)870 741 6658
Luminas Internet Applications Fax: +44 (0)700 598 1135
This is not an official statement or order. Web: www.luminas.co.uk