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 [EMAIL PROTECTED] 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
