cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diana Shannon <shan...@apache.org>
Subject Re: cvs disruption
Date Sat, 22 Mar 2003 12:27:53 GMT
Responding to Steven and Stefano here:

On Friday, March 21, 2003, at 05:23  PM, Steven Noels wrote:

> there's a lot of stuff out there and we should be able to work on this 
> as a team. Even if the transition is carefully documented (as you 
> already did at great length), I assume there might be issues, and then 
> it would be good to have a common set of working files, in CVS, when 
> issues arise.

See below. It's not only about carefully documenting a transition but 
also  about completing the transition outside of the cvs. Whether the 
working files (build files and a few configuration files) lived in 
Forrest or Cocoon cvs, didn't matter to me. It was the idea of using ant 
to set up a virtual cvs environment until changes were complete and then 
checking them into cvs. The idea was not to break existing builds until 
transition was complete. Nothing more.

AND

On Saturday, March 22, 2003, at 04:53  AM, Stefano Mazzocchi wrote:

> Inside, we are all equal so once you get it can either be a democracy 
> (ask first, wait for momentum to build, potentially forever) or a 
> do-ocracy (do first, rollback if they jump on you or keep going if you 
> feel you're right).
>
> Diana or anybody else: there is something that bugs you and nobody is 
> stepping up to the plate to do it and no momentum is building and 
> nobody seems to care?
>
> just do it!

Ah, but I did "do" something. The in-process content and configuration 
files simply didn't "live" in the cvs because doing so would have broken 
the existing and future docs build indefinitely. Granted, most of that 
was due to the fact Forrest, at that time, didn't yet convert doc-v10 
docs on the fly which is no longer the case (i.e. I would have had to 
check in doc-v11 versions of all docs).

Please understand, I'm **not** trying to judge how you refactored the 
build. Perhaps in your case, there was no other way to implement the 
changes. I guess I was hoping to suggest -- given the power of ant -- 
that we can set up prototype cvs environments where we can learn about 
the implications of our changes over time, even if the cvs changes under 
our feet, without disrupting the work of others. While our cvs was 
"officially" alpha (even though not all committers knew that) it is 
clear from the past few weeks of feedback that a number of people 
**perceived** our cvs as "almost beta" (thanks to all the great 
bug-fixing we have here) and were using it as "beta" -- right or wrong.

I guess I'm questioning the timing of disruptive cvs changes, so close 
to a beta release date. Perhaps it's just the nature of open source 
software, that a tremendous amount of energy is unleashed right before a 
release  date. 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. 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?

Again, I'm just trying to learn here. Not trying to pass judgment.

Diana





Mime
View raw message