cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [VOTE] Woody scratchpad area
Date Thu, 12 Feb 2004 18:24:03 GMT
I'm -0 for the idea of a Woody scratchpad. We are also using Woody in 
development projects so I understand your concerns. But I believe that 
creating a Woody scratchpad area right now would make more harm than good.

I think there are two main reasons for puting something in a scratcharea:

* You have writen components or even a block where you think that more 
evaluation is needed before we know if the interfaces are good enough or 
maybe that the whole functionality should be delivered in some other 
way. This says nothing about the code quality, it might be ready for 

* The component might be to buggy or at least have been tested to little 
of to be suitable for a production environment.

IMHO the first point is a legitimate reason for puting something in a 
scratchpad. But for Woody the whole block is marked as unstable, so what 
would it mean to put something in the woody-scratchpad? When we have 
created the first release of CocoonForm I think it will make sense to 
have a scratchpad for adding new widgets, datatypes, stylesheets etc.

 From Antonios and your comments I get the impression that you more 
think about the scratchpad as a place for possibly "buggy" parts of the 
code. I'm not certain about this, I think that the code quality will be 
better if more people test the code. If we start to intensionally check 
in experimental code that not even compile I am afraid that the effect 
will be the opposite from propose below. The Cocoon-2.2 branch is a good 
example in this area. When Berin gave up his refactoring the code didn't 
compile, it took some months before it become compilable again, thanks 
to Unicos and others heroic efforts. Non compiling or inconsisten code 
creates a large threshold for other developers.

I think continuos testing and _small_ refactoring steps, is a much safer 
way to develop. Especially in projects with many participants.


Tim Larson wrote:

>You know how we follow a model like:
>  Start:   idea -> design -> implementation ->
>  Repeat:  revise design -> revise implementation ->
>  Finally: test/deploy/etc.
>Right now we have limited points in time when we can
>collaborate on implementation, specifically during the
>"revise design" step.
>I would like to be able to collaborate during the
>"implementation" and "revise implementation" steps.
>This would mean being permitted to commit partial
>implementations that may not be internally consistent
>yet or even compile successfully.  Think of it as taking
>us one step closer to having an environment like
>SubEthaEdit ( )
>for creating *source code* together.
>The proposed Woody Scrachpad (or branch) could be a
>test ground for this idea, as well as serving the
>functions described earlier in this thread for the
>development of experimental features.
>On Thu, Feb 12, 2004 at 09:55:56AM -0600, Hunsberger, Peter wrote:
>>We don't use the Dev branch precisely because it is evolving; I don't
>>expect it to be stable until a release is made.  It only makes sense to
>>me to do things in the scratchpad if what you are going to be working on
>>is going to cross release boundaries.  But perhaps that is what you had
>>in mind?
>Yes, the development of the experimental features is
>likely to span across releases.  Class/new/union/struct
>being developed and soon being converted to something
>similar to what is described on the WoodyScratchpad
>wiki page is already spanning releases, since we managed
>to get 2.1.4 out the door.
>--Tim Larson

View raw message