You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Sanjiva Weerawarana <sa...@watson.ibm.com> on 2002/09/23 18:32:06 UTC

managing change during the 1.0 release process

Hi Guys,

IMO everyone needs to constrain their changes at this stage if 
there is to be any real hope of getting 1.0 out this year. In 
stuff I've released, once something in RC stage *nothing* changes
except bug fixes. Changing user-level APIs is absolutely out, as
is changing any internal guts for "cleaner guts" purposes. 

I think Rick's frustration is reasonable. Dims, I find it a bit
hard to accept the position that users should file test cases
for functionality they've gotten used to in a beta/RC stage that
they'd like to keep. The reason to go from alpha to beta is (and 
was, even here) to signal to users that things are somewhat stable.

I suggest that we develop a precise list of what needs to be done
for 1.0 and do *nothing* but that. Reject EVERY other change. Yep,
that's pretty damn draconian, but that's the only way to get such
a big beast like Axis completed and out the door. This is especially
true for 1.0. 

If all committers don't agree to this then I am not at all 
confident this will get done in 2002.

Sanjiva.



Re: managing change during the 1.0 release process

Posted by Steve Loughran <st...@iseran.com>.
----- Original Message -----
From: "Davanum Srinivas" <di...@yahoo.com>
To: <ax...@xml.apache.org>
Sent: Monday, September 23, 2002 10:20
Subject: Re: managing change during the 1.0 release process


> Sanjiva,
>
> Yes, i agree that we should lock-down changes at this time or we will
never get the product out. I
> was simply saying that some of the problems occur because of unintentional
changes, which can be
> prevented by a strong test suite early in the cycle.
>

Maybe the problem is that Axis, as with any networked app, is a dog to test.
The more tests we get, the better, but it is hard to set up some test
constructs (high latency connections, transatlantic links, etc) and have
everyone run them before committing changes.

-steve


Re: managing change during the 1.0 release process

Posted by Davanum Srinivas <di...@yahoo.com>.
Sanjiva,

Yes, i agree that we should lock-down changes at this time or we will never get the product out. I
was simply saying that some of the problems occur because of unintentional changes, which can be
prevented by a strong test suite early in the cycle.

Thanks,
dims

--- Sanjiva Weerawarana <sa...@watson.ibm.com> wrote:
> Hi Guys,
> 
> IMO everyone needs to constrain their changes at this stage if 
> there is to be any real hope of getting 1.0 out this year. In 
> stuff I've released, once something in RC stage *nothing* changes
> except bug fixes. Changing user-level APIs is absolutely out, as
> is changing any internal guts for "cleaner guts" purposes. 
> 
> I think Rick's frustration is reasonable. Dims, I find it a bit
> hard to accept the position that users should file test cases
> for functionality they've gotten used to in a beta/RC stage that
> they'd like to keep. The reason to go from alpha to beta is (and 
> was, even here) to signal to users that things are somewhat stable.
> 
> I suggest that we develop a precise list of what needs to be done
> for 1.0 and do *nothing* but that. Reject EVERY other change. Yep,
> that's pretty damn draconian, but that's the only way to get such
> a big beast like Axis completed and out the door. This is especially
> true for 1.0. 
> 
> If all committers don't agree to this then I am not at all 
> confident this will get done in 2002.
> 
> Sanjiva.
> 
> 


=====
Davanum Srinivas - http://xml.apache.org/~dims/

__________________________________________________
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
http://sbc.yahoo.com