You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by Steven Noels <st...@outerthought.org> on 2003/03/24 20:38:32 UTC
tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
(follow up to cocoon-docs please)
On 24/03/2003 7:31 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:
results so far:
[ ] creation of cocoon-docs module: morrijr, shannon, stefano,
bdelacretaz
not sure because of comments: sylvain
not sure because of 0.x vote: haul
not eligible but almost a committer: andrew
[ ] docs should stay in src/documentation of the code tree
module(s): jefft, nicolaken, pier, stephan
... which means we could use some more votes do establish genuine
consensus...!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Steven Noels wrote:
>
>> [ ] creation of cocoon-docs module: morrijr, shannon, stefano,
>> bdelacretaz
>> not sure because of comments: sylvain
>
+1
Vadim
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Steven Noels wrote:
>
>> (follow up to cocoon-docs please)
>>
>> On 24/03/2003 7:31 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:
>>
>>
>>
>> results so far:
>>
>> [ ] creation of cocoon-docs module: morrijr, shannon, stefano,
>> bdelacretaz
>> not sure because of comments: sylvain
>
>
>
> In order to remove the "not sure" : I'm firmly +1 for a cocoon-docs module.
>
> The comments were about the transition period before the new doc system
> is fully operational, in which we should take care to still be able to
> build the "old" docs to avoid a "no-docs" period.
We are already able to build the docs using forrest. Try the following:
cvs checkout cocoon-2.1
cvs checkout xml-forrest
cd xml-forrest
./build.sh dist-shbat
cd ../cocoon-2.1
./build.sh forrest
they key is to have the two cvs modules living side by side and
preparing the shbat dist (what a stupid name, anyway) first.
Stefano.
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Steven Noels wrote:
> (follow up to cocoon-docs please)
>
> On 24/03/2003 7:31 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:
>
>
> results so far:
>
> [ ] creation of cocoon-docs module: morrijr, shannon, stefano,
> bdelacretaz
> not sure because of comments: sylvain
In order to remove the "not sure" : I'm firmly +1 for a cocoon-docs module.
The comments were about the transition period before the new doc system
is fully operational, in which we should take care to still be able to
build the "old" docs to avoid a "no-docs" period.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 27 March 2003 21:48, Jeff Turner wrote:
> Nooooo.. not more voting! ;)
Can't voting be better automated, instead of a lot of +1 emails, that are hard
to count (does anyone ever count?).
Niclas
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
Posted by Steven Noels <st...@outerthought.org>.
On 27/03/2003 14:48 Jeff Turner wrote:
> Nooooo.. not more voting! ;)
>
> How about we just *try* cocoon-docs. If it turns out to be a
> sufficiently bad idea, scrap it.
>
> Sigh.. suppose we have to vote on that. Can't win either way ;)
Gee. I'll vote against voting. Does that help? ;-D
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 27 mars 2003, à 15:17 Europe/Zurich, Pier Fumagalli a écrit :
> ...
> +1 :-) Should I open the repo?
+1.
As I understand there are no risks associated with this, just need
indicate in the announcement that commits to this will affect
cocoon-2.1 too, so voting is probably not required for a "test phase"
IMHO.
-Bertrand
Re: tallying [Re: [vote] micro-decision for docs: creation of
cocoon-docs CVS module]
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Jeff Turner" <je...@apache.org> wrote:
> How about we just *try* cocoon-docs. If it turns out to be a
> sufficiently bad idea, scrap it.
+1 :-) Should I open the repo?
Pier
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
Posted by Jeff Turner <je...@apache.org>.
On Thu, Mar 27, 2003 at 02:16:02PM +0100, Bertrand Delacretaz wrote:
> Le Jeudi, 27 mars 2003, à 13:52 Europe/Zurich, Diana Shannon a écrit :
>
> >...
> >I think a discussion intermixed with a vote changes the vote so that
> >people end up voting on different issues -- with no clear cut result.
>
> Agreed - in this particular case, the best thing might be to cancel the
> current vote and make a new proposal (taking into account the
> "cocoon-docs alias" stuff)?
> This would make sure everyone's on the same wavelength before voting.
Nooooo.. not more voting! ;)
How about we just *try* cocoon-docs. If it turns out to be a
sufficiently bad idea, scrap it.
Sigh.. suppose we have to vote on that. Can't win either way ;)
--Jeff
> Steven, you started the original vote, what do you think?
>
> -Bertrand
>
Re: tallying [Re: [vote] micro-decision for docs: creation of
cocoon-docs CVS module]
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Bertrand Delacretaz" <bd...@codeconsult.ch> wrote:
> -Pier suggested [1] using a CVS alias to have cocoon-docs point to the
> src/docs directory of the current code repository (but I don't think he
> said how hard/easy/quick this is to implement).
Null brainer! :-)
Pier
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 27 mars 2003, à 14:31 Europe/Zurich, Steven Noels a écrit :
> ...It's good to see that the 'requirement' to vote adds some energy to
> the discussion, but then again, you, Diana & David are mostly right
> when suggesting that vote was premature and underspecified. I'm the
> hero of underspecification, but keep that silent. :-D
I don't want to speak for others but I thank you for starting the vote,
it lead to interesting discussions...
(ok, maybe starting it on both -dev and -docs was a suboptimal idea, it
might be better to just send an announcement of the vote to the other
list in such cases ;-)
I might be biased by my own understanding of the whole thing but here's
where I think we are:
-general agreement on the need for a separate cocoon-docs repository
-Pier suggested [1] using a CVS alias to have cocoon-docs point to the
src/docs directory of the current code repository (but I don't think he
said how hard/easy/quick this is to implement).
-I suggested [2] moving the alias to the new CVS when a release is done
(which was probably implicit in Pier's proposal).
So the proposal should probably be along the lines of "creating a
cocoon-docs repository that is an alias of cocoon-2.1/src/docs and
moving the alias to the new repository when a release is done".
-Bertrand
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104853357923160&w=2
[2] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104867380029850&w=2
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
Posted by Steven Noels <st...@outerthought.org>.
On 27/03/2003 14:16 Bertrand Delacretaz wrote:
> Le Jeudi, 27 mars 2003, à 13:52 Europe/Zurich, Diana Shannon a écrit :
>
>> ...
>> I think a discussion intermixed with a vote changes the vote so that
>> people end up voting on different issues -- with no clear cut result.
>
>
> Agreed - in this particular case, the best thing might be to cancel the
> current vote and make a new proposal (taking into account the
> "cocoon-docs alias" stuff)?
> This would make sure everyone's on the same wavelength before voting.
>
> Steven, you started the original vote, what do you think?
It's good to see that the 'requirement' to vote adds some energy to the
discussion, but then again, you, Diana & David are mostly right when
suggesting that vote was premature and underspecified. I'm the hero of
underspecification, but keep that silent. :-D
Personally, I find it difficult to follow the current discussion, so if
somebody would be able to summarize (as a proposal), this will help (at
least stupid me ;-)
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
Posted by Diana Shannon <sh...@apache.org>.
On Thursday, March 27, 2003, at 08:16 AM, Bertrand Delacretaz wrote:
> Agreed - in this particular case, the best thing might be to cancel the
> current vote and make a new proposal (taking into account the
> "cocoon-docs alias" stuff)?
Wasn't Pier going to experiment with this approach and report back? If
so, shouldn't we wait[1] for his feedback? Pier?
Diana
[1] There she goes again, using the #&!? word "wait" ;-)
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Jeudi, 27 mars 2003, à 13:52 Europe/Zurich, Diana Shannon a écrit :
> ...
> I think a discussion intermixed with a vote changes the vote so that
> people end up voting on different issues -- with no clear cut result.
Agreed - in this particular case, the best thing might be to cancel the
current vote and make a new proposal (taking into account the
"cocoon-docs alias" stuff)?
This would make sure everyone's on the same wavelength before voting.
Steven, you started the original vote, what do you think?
-Bertrand
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs CVS module]
Posted by Diana Shannon <sh...@apache.org>.
On Wednesday, March 26, 2003, at 10:52 PM, David Crossley wrote:
>>
>> Hm. Could be, although this particular subject has been discussed,
>> semi-proposed and whatnot already at some serious length in the
>> past, the usual circular discussion following suit hereafter.
>
> I only ever saw haphazard discussion, never a clear proposal,
> and then suddenly a vote. The discussion then had to happen
> mixed up with the vote. This approach does not seem to work.
I think a discussion intermixed with a vote changes the vote so that
people end up voting on different issues -- with no clear cut result.
Diana
Re: tallying [Re: [vote] micro-decision for docs: creation of
cocoon-docs CVS module]
Posted by David Crossley <cr...@indexgeo.com.au>.
Steven Noels wrote:
> David Crossley wrote:
<snip/>
> >
> > I think that the murkiness is a result of not having
> > a proposal and subsequent discussion before calling
> > a vote.
>
> Hm. Could be, although this particular subject has been discussed,
> semi-proposed and whatnot already at some serious length in the
> past, the usual circular discussion following suit hereafter.
I only ever saw haphazard discussion, never a clear proposal,
and then suddenly a vote. The discussion then had to happen
mixed up with the vote. This approach does not seem to work.
> IMHO, only you and Diana are feeling confident with the current
> documentation 'system' (please consider this to be a sincere
> compliment). Of course, this situation is wrong.
Actually, i do not feel at all confident (thanks for the compliment).
I have been keen to have an improved system for a long time.
> Therefore, I'm on a quest for a clean-sheet approach. I see two (!) main
> areas:
>
> - the website, with some general purpose info, and Cocoon primers
> - Cocoon documentation, which is a mix of serious hand-written
> reference material, and some generated stuff, which is properly
> versioned and closely attached to a certain release version - no more
> CVS syncing anymore.
I see that second item as still being published on the website.
> Sigh. I assume this is some pattern in (community?) development: "at a
> certain point in time, people will want to start from scratch in order
> to proceed, and the historical past is only a burden then". Or is it
> just my own laziness when it comes to proper refactoring?
Well i think that refactoring should "build upon" previous
work rather than "destroy and re-build". Starting from scratch
would be okay, as long as any old work that was still relevant
was built back in again. Often valuable work gets hidden in the
CVS Attic, perhaps with good intentions to bring it back during
second stage of refactoring. When it gets forgotten, then that
is a community killer.
--David
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
Posted by Steven Noels <st...@outerthought.org>.
On 26/03/2003 7:02 David Crossley wrote:
> I think that the murkiness is a result of not having
> a proposal and subsequent discussion before calling
> a vote.
Hm. Could be, although this particular subject has been discussed,
semi-proposed and whatnot already at some serious length in the past,
the usual circular dicussion following suit hereafter.
IMHO, only you and Diana are feeling confident with the current
documentation 'system' (please consider this to be a sincere
compliment). Of course, this situation is wrong.
Therefore, I'm on a quest for a clean-sheet approach. I see two (!) main
areas:
- the website, with some general purpose info, and Cocoon primers
- Cocoon documentation, which is a mix of serious hand-written
reference material, and some generated stuff, which is properly
versioned and closely attached to a certain release version - no more
CVS syncing anymore.
Sigh. I assume this is some pattern in (community?) development: "at a
certain point in time, people will want to start from scratch in order
to proceed, and the historical past is only a burden then". Or is it
just my own laziness when it comes to proper refactoring?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: tallying [Re: [vote] micro-decision for docs: creation of
cocoon-docs CVS module]
Posted by David Crossley <cr...@indexgeo.com.au>.
Steven Noels wrote:
<snip/>
>
> Yep, this is quite some murky vote, and some tallying indeed does help.
I think that the murkiness is a result of not having
a proposal and subsequent discussion before calling
a vote.
--David
Re: tallying [Re: [vote] micro-decision for docs: creation of
cocoon-docs CVS module]
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 24/3/03 8:41 pm, "Steven Noels" <st...@outerthought.org> wrote:
> IIRC, you can't alias a dir to a _dir_ of another module, at least that
> was what I was trying to do. Symlinking serverside will not work, I
> assume...?
Nope, alias wouldn't work, but symlink would (although I don't like them
"that much").
Pier
Re: tallying [Re: [vote] micro-decision for docs: creation of
cocoon-docs CVS module]
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 24/3/03 8:41 pm, "Steven Noels" <st...@outerthought.org> wrote:
> IIRC, you can't alias a dir to a _dir_ of another module, at least that
> was what I was trying to do. Symlinking serverside will not work, I
> assume...?
Nope, alias wouldn't work, but symlink would (although I don't like them
"that much").
Pier
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
Posted by Steven Noels <st...@outerthought.org>.
On 24/03/2003 21:30 Pier Fumagalli wrote:
> Steven... I didn't say that the documentation should reside in the
> src/documentation... I lean (on the other hand) quite on the other side of
> the fence, because I know that if someone wants to have those docs in
> src/documentation, we can make this happen easily like the HTTP project does
> with its documentation... :-)
Oops - sorry :-)
Yep, this is quite some murky vote, and some tallying indeed does help.
I understood you the other way around, i.e. cocoon-docs being the cvs
module alias of src/documentation of cocoon-2x (yep, I forgot about CVS
aliasing, though I messed around already with it once)
The way I understand it now, maybe this setup might work:
cocoon-docs:
src\
documentation\
v20
v21
tools
cocoon-2x:
src\@documentation -> being an alias to module
cocoon-docs\src\documentation\v2x
IIRC, you can't alias a dir to a _dir_ of another module, at least that
was what I was trying to do. Symlinking serverside will not work, I
assume...?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: tallying [Re: [vote] micro-decision for docs: creation of cocoon-docs
CVS module]
Posted by Steven Noels <st...@outerthought.org>.
On 24/03/2003 21:30 Pier Fumagalli wrote:
> Steven... I didn't say that the documentation should reside in the
> src/documentation... I lean (on the other hand) quite on the other side of
> the fence, because I know that if someone wants to have those docs in
> src/documentation, we can make this happen easily like the HTTP project does
> with its documentation... :-)
Oops - sorry :-)
Yep, this is quite some murky vote, and some tallying indeed does help.
I understood you the other way around, i.e. cocoon-docs being the cvs
module alias of src/documentation of cocoon-2x (yep, I forgot about CVS
aliasing, though I messed around already with it once)
The way I understand it now, maybe this setup might work:
cocoon-docs:
src\
documentation\
v20
v21
tools
cocoon-2x:
src\@documentation -> being an alias to module
cocoon-docs\src\documentation\v2x
IIRC, you can't alias a dir to a _dir_ of another module, at least that
was what I was trying to do. Symlinking serverside will not work, I
assume...?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: tallying [Re: [vote] micro-decision for docs: creation of
cocoon-docs CVS module]
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 24/3/03 7:38 pm, "Steven Noels" <st...@outerthought.org> wrote:
> (follow up to cocoon-docs please)
>
> On 24/03/2003 7:31 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:
>
> results so far:
>
> [ ] creation of cocoon-docs module: morrijr, shannon, stefano,
> bdelacretaz
> not sure because of comments: sylvain
> not sure because of 0.x vote: haul
> not eligible but almost a committer: andrew
>
> [ ] docs should stay in src/documentation of the code tree
> module(s): jefft, nicolaken, pier, stephan
>
> ... which means we could use some more votes do establish genuine
> consensus...!
Steven... I didn't say that the documentation should reside in the
src/documentation... I lean (on the other hand) quite on the other side of
the fence, because I know that if someone wants to have those docs in
src/documentation, we can make this happen easily like the HTTP project does
with its documentation... :-)
Pier
Re: tallying [Re: [vote] micro-decision for docs: creation of
cocoon-docs CVS module]
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 24/3/03 7:38 pm, "Steven Noels" <st...@outerthought.org> wrote:
> (follow up to cocoon-docs please)
>
> On 24/03/2003 7:31 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:
>
> results so far:
>
> [ ] creation of cocoon-docs module: morrijr, shannon, stefano,
> bdelacretaz
> not sure because of comments: sylvain
> not sure because of 0.x vote: haul
> not eligible but almost a committer: andrew
>
> [ ] docs should stay in src/documentation of the code tree
> module(s): jefft, nicolaken, pier, stephan
>
> ... which means we could use some more votes do establish genuine
> consensus...!
Steven... I didn't say that the documentation should reside in the
src/documentation... I lean (on the other hand) quite on the other side of
the fence, because I know that if someone wants to have those docs in
src/documentation, we can make this happen easily like the HTTP project does
with its documentation... :-)
Pier