cocoon-dev mailing list archives

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

I agree with your analysis, especially with "probably the most realistic
alternative".  We need to deal with the reality that Woody/CForms is
becoming standard equipment due to the lack of a suitable stable
alternative that can answer to its feature-set.  Woody is still officially
alpha, but reality dictates that we be more careful about changes than we
would be with alpha software that is not getting as much real-world use.

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

Looking forward to hearing from you :)

> >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 
> ourselves.
> 
> 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 ;)

The concerns you express here are what drove me to suggest this
scratchpad idea.  I want to open the *implementation process* to public
scrutiny.  Currently I discuss with this list the potential feature
changes and possible designs for implementing them, but then the actual
implementation process is mostly private, because without CVS or other
version control it is hard for other developers to examine, comment on,
and assist in the implementation.

By moving this private process into a sandbox in the public CVS archive
I hope to get more input *during* the process instead of shocking people
when it is finished and having to do major reworking of the implementation
based on their necessarily delayed input.

I know a scratchpad area will get less testing than the main line, but
at least it has the potential to get more public testing than a private
implementation process would get.  What do you think in light of this
motivation?

> >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
> >blocks.
> >
> >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 have thought of setting up my own public facing cvs server to make
my ongoing implementation efforts available for collaboration and review,
but hit two issues:  The big issue is that I do not want to pull, or even
appear to pull, development away from the cocoon community.
The small issue is technical and probably made irrelevant by the first
issue: I do not know how give a piece of code in effect two home cvs
repositories without incurring the wrath of the CVS metadata and having
to use repeatedly use clumsy metadata conversion scripts.

Using my own public facing cvs server could help solve the serialization
issue, but I think the negative community effects might be to big for
this to work well.  I am open to alternative suggestions if anybody has
other ideas how to solve this.  Maybe I am just hitting a social side
effect of the technical difficulties of using multiple branches in CVS.

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

Amen.  However, some worthwhile project do not break down well into
small refactoring steps.  These have to be undertaken only with due
consideration, but sometimes they have to be done.  For these cases
it would help to have a way to share the implementation and review
workload *while the code is being written*.  Maybe this is too hard
to support using CVS?

--Tim Larson

Mime
View raw message