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
