cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <>
Subject Re: [VOTE] Woody scratchpad area
Date Thu, 12 Feb 2004 19:29:20 GMT
On Thu, Feb 12, 2004 at 07:24:03PM +0100, Daniel Fagerstrom wrote:
> 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.

Thank you for taking the time to consider and comment on this proposal.

> 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.

This is exactly the main reason for a Woody Scratchpad.  In my case, I
have several concepts that I want to implement, but that will need more
evaluation *after* they are created to determine if they are the best
concepts or if fundamental changes are required.

For examples, please see the WoodyScratchpad wiki page for the ongoing
developments that are replacing the class and new widget definitions
with id/defines/extends attributes and replacing union with a new choice
widget that has different semantics.  These examples, adding support for
widget definition repositories, and other ideas I may not have mentioned
yet all require changes to the core of Woody, in some cases changing
interfaces, changing the form and binding manager classes, touching all
of the widget definition classes, etc.

I do not like introducing this type of *design* instability to the base
Woody implementation.  After the exploration is done, and the best
options have been found, then it would be a good time to import these
features into the mainline Woody implementation, documentation, etc.

This first proposal is what the vote was raised for.  The second
proposal should be considered separately with a *separate* vote later.
More comments on this below...

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

To reiterate, the proposal being voted on is not about allowing lower
code quality in CVS, but for allowing design exploration to occur more
freely without fear of upsetting existing Woody installations by
repeatedly changing widget names, semantics, etc. during this evaluation
phase.  Sorry I did not clearly divide my second proposal from this one.
As I understand it, this is all that the current vote covers.

> 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.

If we were just adding a new widget that would be fine, but many of the
exploratory enhancements hit too many core parts of Woody to be handled
that way.

> 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.

Now we are talking about the second proposal, which is *not* being voted
on right now.  For this proposal, try to think in terms of "viewing and
participating in active implementation" instead of thinking "buggy".

This style of CVS use would require a separate blocks that are excluded
from the build by default, somewhat similar to to how one or more of the
database-related blocks were handled when they were younger, to prevent
build errors for people not interested in these live-collaboration

To prevent stale, stalled development from corrupting the code, we could
put a time limit on how long a compile-or-run-breaking commit can live
before it must be rolled back.  Because the commit will still live in
cvs history, a rollback would not have to be a controversial issue.
When someone wants to resurrect a rolled back change they could just do
a dated checkout, locally update the changes to not break the compile or
run and then check the repaired changes back into cvs head.

A time limit of a few-days-to-a-week may be appropriate, shortening the
time if an unfinish feature breakage is holding up shared testing of
another not-stalled feature that is in development.

> 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:
Text snipped since this email is already too long, but here's the link:

--Tim Larson

View raw message