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 production.
* 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.
/Daniel
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 ( http://www.codingmonkeys.de/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.
WDYT?
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
