cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] what cocoon is doing wrong
Date Tue, 25 Feb 2003 22:37:07 GMT
Nicola Ken Barozzi wrote:

<snip/>

>> Scratchpad considered harmful
>> -----------------------------
>>
>> I proposed to remove the scratchpad and no consensus was reached. I 
>> try again but this time harder: I think the scratchpad is harmful.
>>
>> Reasons:
>>
>> 1) for non-core stuff, alpha blocks will do just fine and will even 
>> keep libraries out of the way.
> 
> 
> I agree *only* if you put them in a separate dir. Test code with normal 
> code is even more *harmful* than dead code.

We need to tame the mess.  See below.

>> 2) if you want to try things around with core stuff, I *WANT* you to 
>> do it on the head. It's called 'continous integration'. No, dude, I 
>> won't make it easier for you, I want it to make it harder so that 
>> everybody sees what you're doing and can improve on it.
>>
>> I repeat my proposal to kill the scratchpad
> 
> 
> Hmmm... how could we have done the flow without the scratchpad?
> Do you really think that Schecoon could have been done in head?
> 
> Make the scratchpad-blocks dir, and that will automatically solve many 
> of these problems and clear the scratchpad.
> 
> Let's KISS. Let's start with the obvious. Move the scratchpad into 
> scratchpad-blocks and see what's left. We may be surprised.


Taming the Mess
---------------

The Cocoon CVS structure is a mess.  We have source directories all over
the place, JARs all over the place (some of which are duplicates), and
it seems like you need a Ph.D. just to understand what is going on
where.

Why is this the case?

* Several scratchpad ideas/concepts would have been better implemented
   as a separate project that *depended* on Cocoon.
* Scratchpad allowed uncontrolled innovation.  That has its plusses and
   minuses.  It allows us to attempt to use bleeding edge technologies,
   with the understanding that the dependency libraries would be changing
   underneath us.
* Things linger in scratchpad longer than they should.  A concept gets
   started and then the community (or developer) gets sidetracked on
   something else.

What would removal of the Scratchpad force on the community?

* More controlled innovation.  Instead of anybody using it as their
   personal playground, it would force the development to be more in
   the face of the community.
* Better concept of exactly what is in Cocoon.  After not being active
   for a while and comming back, I don't even recognize the project.
   How many of the current developers know *all* of what is in the
   CVS archive?
* If the community doesn't want to support it, move it someplace else.
   IOW if the community doesn't want some code in the main trunk it is
   for a very good reason.  The proposing developer would be encouraged
   to incubate the project elsewhere.

I agree that we need to KISS.  The problem is that our definitions of
simple do not mesh.  What we need is a simple way for the developers/
users to know how to embrace and extend Cocoon for their purposes.  At
this very junction, we don't have it.  Through a long iterative process
of doing things one step at a time, we can get there.

I think you might be optimistic with the scratchpad-blocks.  I think
there needs to be a little better education on the CVS structure, and
why things are the way they are.  If we as a community decide that
things need to change, we can at least have a better understanding of
the implications of that change.


Mime
View raw message