On Thu, Feb 12, 2004 at 07:24:03PM +0100, Daniel Fagerstrom wrote: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'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.
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.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.
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?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.
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 ;)
As discussed before, it is not necesarily a drawback, it is key part of distributed innovation.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.
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.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 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.
/DanielI 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: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=107660415221663&w=2
--Tim Larson
