Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3D4E8BB9.3070100@apache.org>
Date: Mon, 05 Aug 2002 10:29:13 -0400
From: "Andrew C. Oliver" <acoliver@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [CLEANCOON] Let's clean Cocoon and modularize it  (was: Cocoon
 Organization (Cocoon plugins))
References: <011201c23c7f$3c9c13d0$df74558b@vgritsenkopc>
 <3D4E825E.6090408@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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