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 Fri, 13 Feb 2004 11:12:27 GMT
Tim Larson wrote:

>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 
>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.
Ok, +1 for this part then ;) This means that we introduce two levels of 
instabillity: The Woody block is instable and the Woody scratchpad is 
very unstable ;) Considering the number of users and the amount of 
documentation it is probably the most realistic alternative, although 
maybe somewhat confusing.

>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.
Yes, these are interesting things, I hope to soon find time to study 
them in greater detail so that I can take part in the design discussions.

>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.
Here we get to more subtle things. You want to change interfaces and 
other things in the core to make it work with the new stuff. If you do 
that within the core you will certainly risk to break things for other 
people and also the devlopment might take longer time as you will have 
to spend time discussing all the interface changes on the list. At the 
surface this might seem like drawbacks, but are they realy?

What happens when you work in the core is that the code will get much 
more testing. People will be much more interested in discussing 
interface changes. I am also certain that other people on the list have 
ideas that will require core changes, enhancements and refactorings. By 
working with core stuff whithin the core all those aspects has a much 
larger chance to be taken into account and we will in the end have a 
much better form framework than anyone of us would be able to build by 

Consider the alternative, I get the impression that you are going to 
fork some parts of the core and base the new stuff on that fork. Ok, you 
are not going to disturb any users with possible bugs, but what happens 
later, when it is time to re-integrate the kernel changes?

The key word IMO is feedback. In the core you will get much of it, in 
the protected are of the scratchpad you will not. Be brave ;)

>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.
As discussed before, it is not necesarily a drawback, it is key part of 
distributed innovation.

>>>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.
My opinion on how long time an intensionally created 
"compile-or-run-breaking" commit should be allowed to live is 0 ;) That 
development style esentially serialize instead of paralellize 
development. If I happen to check out yor broken code I have to either 
fix it, which could be complicated if it is left in the middle of a 
large refactoring or in the middle of some complicated new design. Or I 
have to make a rollback. Or most probably I will wait till you have 
fixed it, and then I might not have time to do anything, or have lost 
interest in the _to_ unstable component.

>>I think continuos testing and _small_ refactoring steps, is a much safer 
>>way to develop. Especially in projects with many participants.
>>Tim Larson wrote:
>Text snipped since this email is already too long, but here's the link:
>--Tim Larson

View raw message