3.1 status check?

[ru...@us.ibm.com]

In prior milestones, I noticed development quieting down prior to ship.  If
anything, I see activity picking up in the last two weeks.  I'm not just
talking about quantity, but many of the kinds of changes I am seeing are
more in the core than the fringe.

This makes me bit nervous about cutting a "final" 3.1 release at this
point.  Most of these changes have not had the benfit of widespread
testing.  Should I create a release candidate instead with a burn in
period?

- Sam Ruby

P.S.  A burn in time might be an excellent time to hammer a roadmap for
what happens beyond 3.1...

Re: 3.1 status check?

["Craig R. McClanahan" <Cr...@eng.sun.com>]

rubys@us.ibm.com wrote:

> In prior milestones, I noticed development quieting down prior to ship.  If
> anything, I see activity picking up in the last two weeks.  I'm not just
> talking about quantity, but many of the kinds of changes I am seeing are
> more in the core than the fringe.
>
> This makes me bit nervous about cutting a "final" 3.1 release at this
> point.  Most of these changes have not had the benfit of widespread
> testing.  Should I create a release candidate instead with a burn in
> period?
>

+1 for RC1 -- but we've got many outstanding bugs (including quite a few in
JSP-land) that would have to go on the FINR (fixed in next rev) list.

Also, are you planning on a synchronized 3.1rc1 release of Ant and Watchdog?
If so, there's a bunch of outstanding Ant issues in Bugzilla as well.

>
> - Sam Ruby
>

Craig

>
> P.S.  A burn in time might be an excellent time to hammer a roadmap for
> what happens beyond 3.1...
>

Working on a suggested way to document the results of this discussion, will be
posted later today.

Re: 3.1 status check?

[MANDAR RAJE <ma...@pathfinder.eng.sun.com>]

I would say that we create a release candidate tomorrow (3.1RC).
Only critical bug fixes should go into 3.1RC, everything else can 
go in the main tree. And then, after a week we call it final.
This will help us have some stability/quality gurantees for the
release. 

I personally don't like the distinction between fixes to 
"unsupported" code and the ones to "supported" code. Fixes
are fixes and can have ripple effects.

Mandar.


Costin Manolache wrote:
> 
> Most of the changes are bug-fixes and changes in "unsupported" components
> ( security, etc ).
> 
> Probably the reason  is the far-too-long burn-in time, if you build a release
> candidate probably a good idea is to mark the tree and let any changes
> to the 3.1RC go in the branch, and leave the main tree open.
> 
> If any _serious_ bug is found - it will have to be merged, but minor fixes
> and improvements don't belong in 3.1 at this stage.
> 
> Costin
> 
> rubys@us.ibm.com wrote:
> 
> > In prior milestones, I noticed development quieting down prior to ship.  If
> > anything, I see activity picking up in the last two weeks.  I'm not just
> > talking about quantity, but many of the kinds of changes I am seeing are
> > more in the core than the fringe.
> >
> > This makes me bit nervous about cutting a "final" 3.1 release at this
> > point.  Most of these changes have not had the benfit of widespread
> > testing.  Should I create a release candidate instead with a burn in
> > period?
> >
> > - Sam Ruby
> >
> > P.S.  A burn in time might be an excellent time to hammer a roadmap for
> > what happens beyond 3.1...
> >
>

Re: 3.1 status check?

[Costin Manolache <co...@eng.sun.com>]

Most of the changes are bug-fixes and changes in "unsupported" components
( security, etc ).

Probably the reason  is the far-too-long burn-in time, if you build a release
candidate probably a good idea is to mark the tree and let any changes
to the 3.1RC go in the branch, and leave the main tree open.

If any _serious_ bug is found - it will have to be merged, but minor fixes
and improvements don't belong in 3.1 at this stage.

Costin



rubys@us.ibm.com wrote:

> In prior milestones, I noticed development quieting down prior to ship.  If
> anything, I see activity picking up in the last two weeks.  I'm not just
> talking about quantity, but many of the kinds of changes I am seeing are
> more in the core than the fringe.
>
> This makes me bit nervous about cutting a "final" 3.1 release at this
> point.  Most of these changes have not had the benfit of widespread
> testing.  Should I create a release candidate instead with a burn in
> period?
>
> - Sam Ruby
>
> P.S.  A burn in time might be an excellent time to hammer a roadmap for
> what happens beyond 3.1...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org