Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <200412130850.iBD8nu8a073192@squid.cmb.ac.lk>
From: "Farhaan Mohideen" <farhaan@opensource.lk>
To: "'Apache AXIS C Developers List'" <axis-c-dev@ws.apache.org>,
   "'Samisa Abeysinghe'" <samisa.abeysinghe@gmail.com>
Subject: RE: Problems with Axis2Transport & SecureChannel that need to be
 fixed before releasing 1.4
Date: Mon, 13 Dec 2004 14:43:28 +0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <a0f0c148041212235156e8e5cb@mail.gmail.com>
Thread-Index: AcTg6WUEkOQ+IeDcT/GmcMZZQGAnwAABNcNA

Good comments Samisa, I would also encourage that everything is documented
before the release on a Release page where we decide on the Alpha, Beta and
Final dates.
http://wiki.apache.org/ws/FrontPage/AxisC_2b_2b

All are welcome to update with their comments. Further per release
identifying what features go in and for each feature the developer should
have some sort of a status on the the following
1. Code complete 
2. API Documentation available 
3. Unit tests
4. Tested environments (eg. Linux & Windows)
5. Samples Passed or Failed
5. Deployment instructions
6. Interfaces the feature depends on and interfaces made available 

We should also have a section on what JIRA issues (especially bugs) should
be closed for a release. This would be a good place to say if some feature
or bug could stop us from releasing a version of Axis C++.

I will update http://wiki.apache.org/ws/FrontPage/AxisC_2b_2b/ReleasePlan1.5
once 1.4 final is released. Sanjaya will send a status update (it looks like
SSL is ready to be shipped) on 1.4 final.

Regards
Farhaan 
-----Original Message-----
From: Samisa Abeysinghe [mailto:samisa.abeysinghe@gmail.com] 
Sent: 13 December 2004 13:51
To: Apache AXIS C Developers List
Subject: Re: Problems with Axis2Transport & SecureChannel that need to be
fixed before releasing 1.4

I too am a fan of "release early and often". Let me add few thoughts
of mine here:

As it has been happening, we usually discuss the release date and
features to be released at least one month before the release date.
Hence I think we have a very good chance of avoiding last minute
mishaps, and deciding what exactly to include in the next release.

I think, learning from the resent past, we could lay out couple of
conventions to get rid of problems with code freezes and releases.
1. Shall we agree on committing all new features two weeks before the
code freeze in case that is only tested by the developer on one
platform and one week before code freeze if the developer tests at
least on two platforms. Given that we plan the releases at least one
month prior I think this is quite feasible. Also, if one feels that
there is too little time, he/she can always schedule the feature to
the release after next.

2. Can we please have some agreement that there would not be any major
changes to the code between alpha, beta and final. This will further
enforce developers to put the features in place for alpha, so that
they would be tested at least two times before final release.

I know that some features which were planned for 1.4 (like
attachments) were put off for 1.5 due to time considerations - which
was a very good thing to do. As we have set a timeline for 1.5
already, if we could place the above two conventions in place for that
we could see how practical and helpful those would be.

It is a fact that no developer could write a piece of code that could
guarantee to work first time. Hence the obvious solution here is to
leave room for enough testing - without rushing the features into a
release.

Also, if we have objections/concerns regarding the timelines, it is
best to discuss them early and come to agreement on those. If I
remember correct 1.4 and 1.5 were discussed well before the start of
month of November 2004.

As this is an open source project and as the collective effort decides
the success of the project, I think as developers, we must all take
collective responsibility on the releases. And, IMHO, each developer,
who takes the responsibility of implementing something would be able
to say if it is possible or not to deliver that feature within the set
delivery date. If the developers are not happy, the best is to
negotiate on the release dates or to postpone the feature to a release
after next.

Thanks,
Samisa...


On Sat, 11 Dec 2004 19:07:16 +0600, Sanjiva Weerawarana
<sanjiva@opensource.lk> wrote:
> Hi John,
> 
> > There are more lessons to be learnt here about the way we are handling
> > releases and testing but we can have those once this release is over.
More
> > comments below.
> 
> If there are problems with how we're doing things those certainly
> need to be addressed.
> 
> BTW, while I'm a big fan of "release early and often" I am a bit
> concerned at the pace of releases of Axis/C++. If the community is
> able to handle it, well, then its awesome. However, your comment
> confirms my sense that the community is not handling it well but
> yet we're going very fast. It seems that slowing down the release
> frequency is very prudent at this time.
> 
> > Indeed, I understand why you say that  - my perspective is also that
*all*
> > the  code should work, whether or not IBM use it  -
> 
> Glad to hear it.
> 
> 
> 
> > I was referring to
> > whether the open-source SSL worked in 1.4 or not.  Absolutely we care
that
> > the code works but if it doesn't for 1.4. then let's just be open about
> it,
> > leave as it is (OK, get it starting using Fred's fixes) and fix and test
> it
> > more thoroughly in 1.5 (see logic below). This will, in my opinion, lead
> us
> > to happier users :-)
> 
> I'd much rather remove the feature than ship it saying "try at at your
> own risk." So if people decide to remove the feature that's fine too,
> but I'm against keeping it if the open source version of it doesn't
> work (but a proprietary version does).
> 
> 
> 
> > > I'm hereby -1'ing this release until the open source SSL version is
> > > working (too).
> >
> > I'm not happy about stopping the release for this code. This code has
not,
> > in my opinion, been tested thoroughly. We are here on the eve of
> > code-freeze for a release, not discussing whether we can fix a bug but
> > discussing whether new function can even run at all ! These are not
small
> > bugs we're talking about here but fundamental "will it start" issues.
> > Whenever I see such fundamental problems this close to a release I stop
> the
> > code not the release.
> 
> Fine, then remove the feature completely .. that's fine too.
> 
> 
> 
> > The issues that Fred has now fixed are simple ones
> > that, as far as I can tell, mean that this code has never been run on
any
> > test machine.  *IF* users are waiting on SSL then let's stop the release
> > until we're happy with the testing and that means, to me, repeatable
tests
> > in the fv-suite. If,  however, no users are waiting on this code then I
> > suggest we go ahead with the release and test the code more thoroughly
in
> > 1.5 and document that this code is un-tested and will be tested more in
> > 1.5.
> 
> IMO its not good enough to say "release untested code". If the situation
> is as bad as you say then let's just pull SSL support. I do believe SSL
> support will get widely used quickly and hence putting out a non-working
> release is unacceptable.
> 
> > I don't think that any of us want to let users down with un-tested code
!
> 
> Excellent! So let's decide which way to go ..
> 
> Sanjiva.
> 
>