cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Date Mon, 05 Aug 2002 14:29:13 GMT
Hi..  I'm not "not replying" - Vadim covered my opinion:

"
Because (IIRC) there is no docs to it. And refactoring, remodularizing,
forresting, etc will not help this situation - as Andrew pointed out.
And I cannot not to agree with him.
"

Anyhow, I'm not a committer, so my -1 is not binding.  Just I hope you realize
how wrong you are before you get to far.  I fear the day when Cocoon is refactored
into a billion unexplainable/undocumented pieces that I can't figure out how to fit together.
I'm currently quite able to install Cocoon with the features I need, and I'm even able to

remove some.  Granted it took me ~6 months to get there, but I got there.  So consider me
the little mouse...the user voice that knows his squeek is irrelevant but squeeks before being

stomped under foot.  Then do what you must.

-=Andy "The Please Document Mouse"

Nicola Ken Barozzi wrote:

>
> Vadim Gritsenko wrote:
>
>>> From: Andrew C. Oliver [mailto:acoliver@apache.org]
>>>
>>>
>>>> If nobody objects, I will branch on 7 August 2002 and start
>>>
>>>
>> refactoring.
>>
>>> Not that my opinion should count for much, but I object. 
>>
>>
>>
>> I'm with you, we are -1.5 now.
>>
>> Ken, shall we do one step at a time, please?
>> (seems that I'm in favor of evolution)
>
>
> This is not evolution.
> Refactoring is never evolution.
>
>>> My objection
>>> is this.  Before there is an agreement and set of documentation
>>> explaining "WHAT goes WHERE" then this will be contentious. 
>>
>>
>>
>> +1. Before we start branching CVS, let's define what goes where. "Cocoon
>> Organization" thread was exactly about this.
>
>
> Why?
> The branch is a playground, where many can *see* the difference 
> instead of just trying to understand it.
>
> If you prefer I can just write the things I will move, but it just 
> seems easier to me to move them and have all evaluate it.
>
> AFAIK there doesn't have to be a vote to branch, but there is to be a 
> vote to switch codebases or to switch back.
>
> For now, I haven't heard compelling reasons not to.
>
>>> Secondly,
>>> I'd like to see something that explains how a common person will go
>>> about installing Cocoon with *feature X* once its split into a billion
>>> complex pieces with UNKNOWN dependancies.  Modularization will only
>>> work
>>> if the modules are defined in a human language.  So far I see a
>>> million
>>> "lets fix it via just hacking at it" approaches, no definitions, and
>>> still inadequate documentation.  Personally, I feel the documentation
>>> is
>>> FAR more important than ANY refactoring at helping users understand
>>
>>
>> Cocoon.
>>
>> +1.
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message