cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: cvs disruption
Date Sun, 23 Mar 2003 07:59:05 GMT
Stefano Mazzocchi wrote:
> Diana Shannon wrote:
> > Stefano Mazzocchi wrote:
> >> Diana Shannon wrote:
> >>
> >>> Perhaps it's just the nature of open source software, that a 
> >>> tremendous amount of energy is unleashed right before a release date.

Actually i do not think that there is a "release date" yet.
That is just "as soon as we can".

I think that the current spurt of activity is from excitement that
we are getting toward a much more stable foundation in general, and
so many people can get productive again.

> >>> Perhaps there's no other way. Still, it feels, to be honest, like 
> >>> poor planning. If we follow the maxim of "release early, release 
> >>> often" I fail to see why there needs to be this kind of disruption 
> >>> before releases.

However, when is it a "good time"? As someone said in another
email ... let us get the disruption over and done with earlier.

> >>> If the releases weren't spaced so far apart, what 
> >>> difference would it make if we need to wait a little longer for some 
> >>> new capability?
> >>
> >> This is a very good point. So, do you suggest to postpone 
> >> forrestization for post-2.1? say for 2.1.1?
> > 
> > Not necessarily. It depends on how much time we still have. And 
> > forrestization can occur in stages.

Yeah, i do not see that we need to wait. This can all
be done in stages.

> > For example, current forrest build capability with cocoon's cvs
> > is only possible with Forrest CVS, not the last Forrest release.
> > This violates your "building on sand" philosophy.

I am not sure what you mean here Diana, it is working now.

> > We can change our cvs to work with 
> > 0.4 Forrest, but it involves committing doc-v11 versions of many files 
> > and deciding what to do with doc-v10-related files. If we simply 
> > eliminate the doc-v10 files, we will break the separate doc-building 
> > capabilities of our webapp documentation set. If we keep both versions, 
> > we have a maintenance nightmare. This is being discussed on cocoon-docs, 
> > with debate on how/if to include Forrest itself in our cvs, but there's 
> > no consensus yet, IMHO. Whatever solution is decided may take some time 
> > and tweaking to implement, that's all. And I would hate for it to hold 
> > up a release.

Yes, this is the main issue. We really wanted to transform
all of the documentation to v1.1 DTD and this has many
ramifications as noted on the Wiki pages. The full job of
transition to the new DTD is rather big. This is the stage
where one person needs to transition the xdocs, then commit
and we all dive in to fix the stylesheets and sitemaps and stuff.

Stephan and others have done one excellent step: getting Forrest
to process the Cocoon docs as they are now (DTD v1.0). Going to
the next stage is what Diana is rightly concerned about.

> All right. Since there is circular dependency between cocoon and 
> forrest, I would suggest we release cocoon 2.1 first, allow forrest to 
> release a new version based on 2.1 and at that point forrestize our docs.
> how does that sound?

But this circular dependency will always be there, so why not
just get on with it. Anyway, Forrest uses a recent stable
version of cocoon-2.1-dev, i.e. just off the bleeding-edge.


View raw message