cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <stev...@outerthought.org>
Subject Re: on better release and version management
Date Thu, 11 Sep 2003 11:38:33 GMT
Reinhard Poetz wrote:

> I expect this and that's the reason why I think that a stable 2.2
> release will take some time (I think that's not a matter of a few months
> but much more) and why I like Carsten's proposal.

Grmbl. Bruno and I were just trying to argumentize against each other 
about both scenarios, and I'm stuck with a few issues that I would like 
the repository reshuffling see resolve.

Here's some feelings (not facts) I want to share with this discussion:

1) There's a decent amount of (positive!) FUD about the new blocks. All 
in all, I don't think that the actual coding of the new classloading and 
block deployment architecture code is much more cumbersome that what 
Sylvain once did with the TreeProcessor, and Stefano did with the build 
system. Yes, it will take time, but it's just a matter of finding time, 
motivation and energy to do the job. We tend to discuss for a long time 
about such issues, possibly longer than the actual coding actually 
requires. In the end, it's about getting on with it, and someone (which 
we will be very grateful for) diving deep into it and resurfacing when 
it's done. Ditto with Fortress. I'm naively hoping that some F2F time 
during the GT will help in finding that energy, and getting some 
commitment from people who need to shift between for-pay and for-free 
work on a daily basis.

2) My main concern with all this restructuring is however release 
management, and the user-facing perspective of our community work. We 
need to arrive to a situation where blocks can be independently released 
from Cocoon core releases, so that people who feel a faster drive to 
work on specific features can get on with the job, without being 
demotivated by long periods of no releases due to one zillion 
dependencies. So maybe we should move all blocks code into a separate 
module, and establish an independent release schedule (at the whim of 
the actual block release manager) for them.

3) This brings us to the eternal discussion about the definition of core 
and non-core. Maybe, be splitting out block code from the main module, 
and actively trying to slim down the main one even more, we will end up 
with a better community sense of what can be considered 'core', and what 
should be consired a block. We could even consider the TraxTransformer a 
block on its own, if we restrict the core to the pipeline, caching, 
sitemap and flow machinery. We could envision a packaged stable build of 
Cocoon which includes the core and then some core blocks. The rest is 
developed and released on its own schedule, and can, given the 
dependency checking in the new blocks paradigm shift (yes, it's more 
about a shift of perception than actual rearchitecturing) be safely 
released outside the main release schedule.

This is just a quick braindump of my current feelings about all this. 
Hopefully it can contribute positively to this recurring discussion. 
Ending on a filosophical note: in the end, we should be driven by hope, 
not by fear. If we manage to come up with a stable 2.1.2 release within 
some weeks, I'm pretty sure our users have plenty of new, stable 
releases to play with while we get our act together.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


Mime
View raw message