cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: cvs disruption
Date Sat, 22 Mar 2003 16:13:55 GMT
Diana Shannon wrote:

> 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. 

*close* is a matter of perception and a matter of removing the stuff on 
the todo list.

I think forrestization is one thing to do *before* release, so better 
sooner and messier than later and cleaner. but that's just me, I have 
high tollerance against mess :)

> 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?

This is a very good point. So, do you suggest to postpone forrestization 
for post-2.1? say for 2.1.1?

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

I know, don't worry.

Stefano.


Mime
View raw message