Switch httpd-2.0 to RTC?

[Justin Erenkrantz <je...@apache.org>]

I don't know how strongly I feel about this, but I think we
deserve to discuss this now that we have a GA.

Should at some point we switch httpd-2.0 to a Review-then-Commit
model?  If so, when?  If not, why not?

I guess I'm scared that someone will start adding things that
will destabilize the server without having it appropriately
reviewed *before* committing.

I'm not going to go on a crusade for this, but I will mention
it so that we can discuss it.  -- justin

Re: Switch httpd-2.0 to RTC?

[Aaron Bannert <aa...@clove.org>]

I'm -1 for RTC until we have a CTR development branch (2.1 or whatnot),
and I don't think we should branch for at least a few more revs of 2.0 GA.
In my mind we alrady require public review for any big changes or new
features, so switching to RTC means that we are nearing the end of the
lifecycle of a release.

that's my 2c,
-aaron


On Mon, Apr 08, 2002 at 05:38:40PM -0700, Justin Erenkrantz wrote:
> I don't know how strongly I feel about this, but I think we
> deserve to discuss this now that we have a GA.
> 
> Should at some point we switch httpd-2.0 to a Review-then-Commit
> model?  If so, when?  If not, why not?
> 
> I guess I'm scared that someone will start adding things that
> will destabilize the server without having it appropriately
> reviewed *before* committing.
> 
> I'm not going to go on a crusade for this, but I will mention
> it so that we can discuss it.  -- justin

Re: Switch httpd-2.0 to RTC?

[Justin Erenkrantz <je...@apache.org>]

On Mon, Apr 08, 2002 at 09:35:01PM -0400, Bill Stoddard wrote:
> -1
> 
> We have been very selective in who gets commit authority and should problems arise, I
> think we (the royal we) will be able to brow beat the offender into line :-)  CTR has
> works fine for Apache 1.3 for a number of years.

My understanding is that Apache 1.3 is under RTC.  We probably
haven't been as stringent enforcing it because most commits haven't
been to the core but to modules like mod_proxy that most of us
don't pay attention to.  -- justin

Re: Switch httpd-2.0 to RTC?

[Bill Stoddard <bi...@wstoddard.com>]

-1

We have been very selective in who gets commit authority and should problems arise, I
think we (the royal we) will be able to brow beat the offender into line :-)  CTR has
works fine for Apache 1.3 for a number of years.

Bill

> I don't know how strongly I feel about this, but I think we
> deserve to discuss this now that we have a GA.
>
> Should at some point we switch httpd-2.0 to a Review-then-Commit
> model?  If so, when?  If not, why not?
>
> I guess I'm scared that someone will start adding things that
> will destabilize the server without having it appropriately
> reviewed *before* committing.
>
> I'm not going to go on a crusade for this, but I will mention
> it so that we can discuss it.  -- justin
>

Re: Switch httpd-2.0 to RTC?

[Jeff Trawick <tr...@attglobal.net>]

Greg Stein <gs...@lyra.org> writes:

> Personally, I view httpd-2.0 as a completely open and active repository. I
> even consider API changes as somewhat acceptable. :-)

> Re: API changes. That is what we have ap_mmn.h for. However, what we've done
> in the past (and I agree with), is that we balance an MMN bump against
> whatever is causing the problem. We don't want to invalidate third-party
> modules just to add some stupid edge case feature.

+1

for *at least* the next few months, long-term pain is minimized by
getting the API right as long as it doesn't require a drastic rewrite
of the module

as time goes on (more modules ported to 2.0, more people following 2.0
releases closely), pain to the community (including us) of changing
the API goes up so the threshhold for what justifies an API change
goes up too

and we shouldn't forget that the APR API affects Apache module authors
too, and that API is probably going to change leading up to APR 1.0
(function renames for one thing)

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: Switch httpd-2.0 to RTC?

[Greg Stein <gs...@lyra.org>]

On Mon, Apr 08, 2002 at 05:38:40PM -0700, Justin Erenkrantz wrote:
>...
> Should at some point we switch httpd-2.0 to a Review-then-Commit
> model?  If so, when?  If not, why not?

Short answer: no, not for a while, see below.

The dev guidelines state:

    "All product changes to the currently active repository are subject to
     lazy consensus. All product changes to a prior-branch (old version)
     repository require consensus before the change is committed."

Thus, the httpd-2.0 repository remains CTR until we open up a new
repository.

The basic story is that developers need a place where they can iterate on
their ideas at their own pace. That is the "active repository".

> I guess I'm scared that someone will start adding things that
> will destabilize the server without having it appropriately
> reviewed *before* committing.

Too bad :-)

You have several options here:

* trust that people are going to be relatively smart about this (my favorite)
* review the change after it was committed; you can always modify the change
  and/or veto it.
* start a new repository / branch / whatever


Note that the 1.3 repository is still operating commit-then-review. By
convention, bug fixes go into that thing as a commit, with a review later.
Feature changes *should* have a patch first, but people have been REALLY BAD
about that (I won't mention names, but will mention that Ken has been *good*
about posting feature change patches first).

Personally, I view httpd-2.0 as a completely open and active repository. I
even consider API changes as somewhat acceptable. :-)

Re: API changes. That is what we have ap_mmn.h for. However, what we've done
in the past (and I agree with), is that we balance an MMN bump against
whatever is causing the problem. We don't want to invalidate third-party
modules just to add some stupid edge case feature.


I would recommend that we continue with httpd-2.0 for a few months. At that
time, we can set up an httpd-2.1 or httpd-3.0 repository (or both!) in
Subversion. Moving to Subversion also neatly avoids the question of whether
to start a new CVS module or to use CVS branches :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/