cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] a simple release plan
Date Thu, 16 Mar 2006 20:02:08 GMT
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> <SNIP/> 
>> Not surprisingly I'm -1 on your points 2 and 3. If you want to continue 
>> in that direction which IMO represents a huge step back. I insist on 
>> that you prove that it work and that you actually have the persistence 
>> to carry it through, on a copy of the trunk in the whiteboard. After 
>> that you need to cast a vote about making that the new trunk.
>> Also it should be much easier to update the Ant scripts than changing 
>> the directory structure.
>> Anyway, why you would like to make such a huge effort in such an 
>> backward pointing direction, instead of helping to finish the blocks 
>> work or at least the M10N, is just beyond my imagination.
> Daniel, as I already said, I appreciate your efforts and blocks are the
> way to go, no doubt. I can only speak for myself, but I see two
> advantages of the plan for me (and hopefully for others as well):
> smaller changes and getting new features today.

Changing back to the old directory structure, throwing the Maven build 
away, and try to get the messy Ant build to work, doesn't seem like such 
a small change to me. IMO, making Maven insert some configuration file 
and samples into cocoon-webapp, should be a much smaller task. And what 
is much more important, it will not split our efforts further or disrupt 
the current development.

Furthermore the switch from ECM++ to Spring you performed, without even 
bother to cast a vote, was a really large and disruptive change.

The Spring/Avalon core is immature and unstable. Right now calls to 
subsitemaps results in NPE:s. Before we got it in at least in a testable 
shape I'm against doing any large restructuring of the trunk.

> I rewrote the core for
> 2.2 nearly two years ago and it never went into a release! The same with
> ECM++, the configuration includes, the property configurations etc. Now,
> we dropped ECM++ in favour of the Spring based container which provides
> the same functionality plus Spring. And it makes totally sense to me to
> release this as a new version.

Sure, as soon as it is usable again.

> There is not much work required for this: if we replace the maven build
> with the ant one, we should have a fully working 2.2 with all the new
> features. So we only have to move/copy some directories and files and
> that's it.

Moving directories is very destructive to do, your suggestion means that 
it would be very hard to synchronize blocks in the release and a 
"block"-branch. And furthermore I still fail to see why it should be 
easier to move around directories than to change some paths in the Ant 

> Speaking for myself again, I can do this stuff as I know how to
> move/copy directories and I now how the 2.2 core works and I'm pretty
> confident that it's working pretty well.

Based on what kind of testing do you say that? For me it doesn't work.

> But I have no clue about blocks or how to finish the maven build. 

You keep saying that you don't understand the blocks. It is not that 
much code at all, and we have written tons of descriptions, and giving 
talks and tutorials on various levels about it during the years. You 
have met me and Reinhard and earlier Stefano IRL plenty of times. I 
haven't heard any specific questions about them from you about it.

So are you really interested in trying to understand them?

> Remember, I suggested a solution two
> weeks ago to get a maven build running, but was told that this is the
> wrong way and we should wait for blocks.

I remember that I told you to go ahead. And that Reinhard asked you to 
wait because he was close to have a working version of the deployer. 
Which he actually had within a week as he said. Unfortunately all the 
blocks stuff stopped working after that you changed the core without 
running the test cases for the blocks.

> And I don't have time to invest
> into blocks or maven right now. That's the simple reason for not being
> able to help. In addition, the current new core with Spring solves all
> my day-to-day problems I have with Cocoon. So why not getting this out?

The core is not your private playground, it is something that the 
community owns together. Work in the core require respect for other 
peoples work.

> And I can't work any further on the core as this always breaks the
> blocks stuff, as you kindly pointed out.

I didn't point it out in a kindly way. I was, once again, deeply 
frustrated that you break core contracts and the tests for the stuff 
that I am developing. If you just did it a few times I would understand 
it, but it have happens so many times during the years. And I have spend 
so much frustrating work in trying to get things working again.

I don't think that it is to ask for to much that you should check that 
the same test cases runs both before and after subtle core changes.

Now, for the latest case with the container switch, I asked you to work 
in a branch until the core was stable again. You didn't care about that 
and you disrupted mine and Reinhard's work, and the core is still not 

> So the blocks stuff is blocking
> the core development - but the blocking in this place is not really the
> problem.

It is not blocking core development, it just means that you need to 
communicate before breaking core contracts. The fact that you are 
breaking the blocks fw might just be an early indication on that you 
changed things that might break less frequently tested blocks and user code.

> It seems to me that our community is a little bit "feature-split" atm.
> One group wants new features today while the other group wants real
> blocks today. I can't tell who's right or wrong and I guess it's unfair
> to talk about right/wrong in this context anyway. But I can tell what I
> want and more important I know what I can do and where I can help.
> Getting a 2.3 out with the proposed plan is doable in the short term imho.

You are free to prove that in a whiteboard branch. But you didn't 
address anything of what I said in my last mail, so nothing has changed, 
you can still expect a -1 from me if you want to carry through your plan.


View raw message