Exactly.
This is also why I suggested that the httpd releases its stable tree. The
proxy team verifies their "current" works against that stable release, then
*they* release an httpd/proxy combo.
The core httpd team does not have the means necessary to ensure that the
current proxy is ready for release. As a result, the release can easily be
shot down due to a problem in the proxy module.
By detaching them, we can keep the httpd releases moving more smoothly.
Cheers,
-g
On Fri, Apr 20, 2001 at 12:50:44AM +0200, Graham Leggett wrote:
> "William A. Rowe, Jr." wrote:
>
> > In a rollup??? Absolutely! The tricky bit will be identifing the last
> > 'stable' release of the apache child projects, overtagging that tag with the
> > apache release version, and letting it fly. I just don't see a simple
> > mechanism (for the RM) to do this all in a free hour :-(
>
> There is no way for the RM to be able to determine which bits of which
> modules are stable or not - therefore it should not have to be up to
> them to do this, but rather the module maintainers.
>
> The maintainers of each of the modules should be responsible for keeping
> a stable version of their module in the rollup tree. If the maintainers
> screw up and commit a broken module and this is uncovered in release
> testing, then the maintainers must fix it immediately, or the RM rolls
> back the changes to the last known working release.
>
> If a module remains consistently broken or unmaintained, the RM has can
> put to vote the removal of the offending module until it is fixed...
>
> This way:
>
> - Broken modules do not hold up the tree
> - The RM can roll a release without going bald
> - Users see a single unified apache release
> - Apache's feature set remains consistent
>
> Regards,
> Graham
> --
> -----------------------------------------
> [EMAIL PROTECTED] "There's a moon
> over Bourbon Street
> tonight..."
--
Greg Stein, http://www.lyra.org/
