The Perils of the Apache Process (WAS: How do I add a non-Commons-type jar to Struts?)

[James Turner <tu...@blackbear.com>]

> David Graham wrote:
> > Commons DBCP and Pool.  I'm trying to work on them but at 
> least DBCP 
> > is
> > in bad shape (IMHO).  Seems like there's not a significant 
> interest in 
> > those components by their original authors so it takes 
> longer for others 
> > to step in and learn them.

This, IMHO opinion, is the biggest weakness of the Apache process, and
is especially bad for Struts.  Because we're dependent on not only
fixing every Struts bug, but fixing every bug in every dependent package
that has a new feature we're using, getting a release done is close to a
nightmare.

I could make a strong argument for instituting three policies going
forward with Struts:

1) No feature from a dependent package can be added into the Struts
source until the feature is available in a final release of the
dependent package.  This means that there is no possibility that we'll
be left hanging waiting for the dependent package to turn a release.

2) Accept that a bug caused by a dependent package (unless agreed by
consensus to be a showstopped for Struts) can be fixed asynchronously by
a release of the dependent package after the main Struts release.

3) For a package is added to the Struts dependency list, it should be
evaluated (at least by the committer who wants to add it) for the
robustness of it's development community.

As to the DBCP / Pool issue, I'd like the hear from David just how bad
things are.  I know we're all volunteers and time estimates are a hard
things to do when it's nights and weekends, but are we talking about
days, weeks or months?  If it's weeks or months, we may need to look at
alternative strategies.

James



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: The Perils of the Apache Process (WAS: How do I add a non-Commons-type jar to Struts?)

[James Mitchell <jm...@apache.org>]

>From related discussions, I think we all pretty much agree with that.

Going forward, what is the consensus on testing?

Do we attempt to implement a "test-first" policy?
I mean (in a perfect world) every item in bugzilla would need 2 files to fix
a valid bug.
1 - A new test that demonstrates a failure and
2 - A patch, which fixes the codebase so that if you apply the patch, then
#1 above passes

Of course, enhancements would probably need a slew of tests to cover new
features.

Your thoughts?


--
James Mitchell
Software Developer/Struts Evangelist
http://www.open-tools.org



----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Monday, April 21, 2003 4:38 PM
Subject: Re: The Perils of the Apache Process (WAS: How do I add a
non-Commons-type jar to Struts?)


> IMHO, the only policy we need to institute is "release early, release
> often".
>
> Where we got into trouble was piling on feature after feature before
> cutting Struts 1.1. (Which at this point, is more like Struts 3.0 in
> terms of features.) Looking back, we could have made at least two point
> releases before integrating Tiles and the Validator. And integrating
> each of those products could have been independent point releases.
>
> The issues with the Commons jars have become critical simply because we
> are trying to ship too many new features at once. If this were Struts
> 2.2, and we were waiting on the DBCP so we could depreciate it 2.3, this
> wouldn't be such a headache.
>
> So once Struts 1.1 ships, I'd like to quickly follow with Struts 1.1.1
> that migrates the messaging to the commons-resources package, and
> continue to make releases on a feature-by-feature basis. Since there
> will be less to test each time, we'll be able to get releases out very
> quickly (perhaps every month).
>
> -Ted.
>
>
> James Turner wrote:
> >>David Graham wrote:
> >>
> >>>Commons DBCP and Pool.  I'm trying to work on them but at
> >>
> >>least DBCP
> >>
> >>>is
> >>>in bad shape (IMHO).  Seems like there's not a significant
> >>
> >>interest in
> >>
> >>>those components by their original authors so it takes
> >>
> >>longer for others
> >>
> >>>to step in and learn them.
> >>
> >
> > This, IMHO opinion, is the biggest weakness of the Apache process, and
> > is especially bad for Struts.  Because we're dependent on not only
> > fixing every Struts bug, but fixing every bug in every dependent package
> > that has a new feature we're using, getting a release done is close to a
> > nightmare.
> >
> > I could make a strong argument for instituting three policies going
> > forward with Struts:
> >
> > 1) No feature from a dependent package can be added into the Struts
> > source until the feature is available in a final release of the
> > dependent package.  This means that there is no possibility that we'll
> > be left hanging waiting for the dependent package to turn a release.
> >
> > 2) Accept that a bug caused by a dependent package (unless agreed by
> > consensus to be a showstopped for Struts) can be fixed asynchronously by
> > a release of the dependent package after the main Struts release.
> >
> > 3) For a package is added to the Struts dependency list, it should be
> > evaluated (at least by the committer who wants to add it) for the
> > robustness of it's development community.
> >
> > As to the DBCP / Pool issue, I'd like the hear from David just how bad
> > things are.  I know we're all volunteers and time estimates are a hard
> > things to do when it's nights and weekends, but are we talking about
> > days, weeks or months?  If it's weeks or months, we may need to look at
> > alternative strategies.
> >
> > James
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Ted Husted,
> Struts in Action <http://husted.com/struts/book.html>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org

Re: The Perils of the Apache Process (WAS: How do I add a non-Commons-type jar to Struts?)

[Ted Husted <hu...@apache.org>]

IMHO, the only policy we need to institute is "release early, release 
often".

Where we got into trouble was piling on feature after feature before 
cutting Struts 1.1. (Which at this point, is more like Struts 3.0 in 
terms of features.) Looking back, we could have made at least two point 
releases before integrating Tiles and the Validator. And integrating 
each of those products could have been independent point releases.

The issues with the Commons jars have become critical simply because we 
are trying to ship too many new features at once. If this were Struts 
2.2, and we were waiting on the DBCP so we could depreciate it 2.3, this 
wouldn't be such a headache.

So once Struts 1.1 ships, I'd like to quickly follow with Struts 1.1.1 
that migrates the messaging to the commons-resources package, and 
continue to make releases on a feature-by-feature basis. Since there 
will be less to test each time, we'll be able to get releases out very 
quickly (perhaps every month).

-Ted.


James Turner wrote:
>>David Graham wrote:
>>
>>>Commons DBCP and Pool.  I'm trying to work on them but at 
>>
>>least DBCP 
>>
>>>is
>>>in bad shape (IMHO).  Seems like there's not a significant 
>>
>>interest in 
>>
>>>those components by their original authors so it takes 
>>
>>longer for others 
>>
>>>to step in and learn them.
>>
> 
> This, IMHO opinion, is the biggest weakness of the Apache process, and
> is especially bad for Struts.  Because we're dependent on not only
> fixing every Struts bug, but fixing every bug in every dependent package
> that has a new feature we're using, getting a release done is close to a
> nightmare.
> 
> I could make a strong argument for instituting three policies going
> forward with Struts:
> 
> 1) No feature from a dependent package can be added into the Struts
> source until the feature is available in a final release of the
> dependent package.  This means that there is no possibility that we'll
> be left hanging waiting for the dependent package to turn a release.
> 
> 2) Accept that a bug caused by a dependent package (unless agreed by
> consensus to be a showstopped for Struts) can be fixed asynchronously by
> a release of the dependent package after the main Struts release.
> 
> 3) For a package is added to the Struts dependency list, it should be
> evaluated (at least by the committer who wants to add it) for the
> robustness of it's development community.
> 
> As to the DBCP / Pool issue, I'd like the hear from David just how bad
> things are.  I know we're all volunteers and time estimates are a hard
> things to do when it's nights and weekends, but are we talking about
> days, weeks or months?  If it's weeks or months, we may need to look at
> alternative strategies.
> 
> James
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 
> 


-- 
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org