cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: [RT] a simple release plan
Date Thu, 16 Mar 2006 13:40:47 GMT
Reinhard Poetz schrieb:
> Upayavira wrote:
>> Carsten has offered a suggestion that _he_ is prepared to implement. I
>> would like to hear other proposals from people of things that _they_ are
>> prepared to implement. Only that way will we move beyond this impass.
> There are many documents that explain the roadmap Daniel and I follow ATM. The 
> only thing we are asking for is that we all work on trunk. Everything else is 
> another internal fork (didn't we agree that this was a bad idea?) and we have to 
> make sure again that everything gets synced again and again. That's the reason 
> for the -1 on Carsten's proposal of Daniel and me.
Hmm, yes, but work on trunk might mean breaking blocks - as my changes
did recently. So it's not that easy. In addition I'm wondering what will
happen with all the work already done on trunk with real blocks? What
about the includes in configuration etc. It more and more seems that
this work is useless for real blocks and is just a waste of time if it
gets never released.

> So what's the overhead for people that want to work on trunk? They should make 
> sure that the testcases run through and they should run the samples before they 
> commit. Is this such a special requirement? Does somebody have to understand in 
> detail what the testcases cover?
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).

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

Carsten Ziegeler - Open Source Group, S&N AG

View raw message