cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [RT] a simple release plan
Date Thu, 16 Mar 2006 14:36:52 GMT

Carsten Ziegeler wrote:
> Trunk is not working out of the box; testing the samples is really a
> pain; for example I can't test the new portal version as this would
> require porting all missing blocks to the new structure, getting them
> compiled and more important its a rather huge effort to build the
> resulting webapp.
> And imho this is a real problem; noone will look at turnk as long as it
> is this way; we scare people away; not to mention that people start
> thinking that moving to maven was the wrong move (I personally still
> think that maven is the right way).
This is exactly my problem. I have stopped applying patches to trunk 
that I am applying to the 2.1 branch because I cannot test them because 
I cannot get a full working Cocoon.  I'm not interested in getting all 
the blocks stuff or maven stuff or whatever to work just to be able to 
apply patches.
>> If a testcase gets broken *locally* by a developer, the developer should discuss

>> the change on dev@cocoon and then people can decide together how to proceed. 
>> That should be the standard procedure in every development project, may it be 
>> opensource or commercial.
>> Can we agree on these very basic rules?
> Some of our test cases are already broken for a long time; so it's hard
> to tell if for example my new changes broke something or if the test was
> already broken; currently I think our tests are not really used.
> But of course I agree with such a rule in general.
> If it would come to a vote, I would personally favour a split.
I love test cases. Frankly, I didn't really know we had any with the ant 
build. I like that the maven build runs them and shows that they fail.  
I hate that no one wants to fix them in trunk.
> Carsten

View raw message