httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Whereforeartthou, 2.5.0?
Date Wed, 10 Jul 2013 13:14:16 GMT
According to STATUS:

    2.4.5   : In development. Jim proposes a release ~July 4, 2013
              and offers to RM.
    2.4.4   : Tagged on February 18, 2013. Released Feb 25, 2013
    2.4.3   : Tagged on August 17, 2012. Released Aug 18, 2012
    2.4.2   : Tagged on April 5, 2012. Released Apr 17, 2012.
    2.4.1   : Tagged on February 13, 2012. Released Feb 21, 2012.
    2.4.0   : Tagged on January 16, 2012, not released.

So I have no idea where you get "6+ mos between releases" of 2.4.x

In any case, I *am* concerned that w seem to have quite a bit of
difficulty in getting 3 +1s a lot of the time and that the backport
process from trunk to 2.4 is becoming more and more painful. After
all, I *assume* people hack trunk so that their code and patches
actually get released and used by people, and not just to bump their
Ohloh ratings or whatever.

And we don't release 2.5.0... We only do even releases, remember?

On Jul 10, 2013, at 2:19 AM, William A. Rowe Jr. <> wrote:

> Fellow PMC folk...
> I think everyone on this list can agree that the pace of releases has
> slowed to a crawl; we are 6+ mos between releases of our active/stable
> 2.4 series, which has little if any adoption, and are equally lethargic
> about the actually stable-and-adopted 2.2 releases.  This is a thread
> which we have visited before many times, but I'd like to throw a new
> spin on it and consider whether we have taken several group decisions,
> and combined them into the worst results possible from the lot of them.
> My question to the group; is /repos/asf/httpd/httpd/trunk/ actually
> a trunk?  Or is it a sandbox?  All ASF projects have one goal, which
> is to release open source code to the public at no charge.  What is
> currently brewing as /repos/asf/httpd/httpd/trunk/ has a version #
> designation, but no plan to release, and no release in several years.
> I would humbly submit that with no plan to release, /trunk/ is simply
> a sandbox, and should be svn mv'ed to the appropriate svn branch for
> those developers to retrieve, maintain and later advance their proposals
> into an actual 2.5.0 release trunk at some future date.
> I'm watching a ton of mental gymnastics by the few who are willing to
> fight with this bureaucracy to commit to a non-release trunk, plea for
> backport votes, then perhaps get their code into 2.4 (which is not yet
> even distributed by anyone other than the ASF and adopted by almost no
> users at all).  The entire model, IMHO, is broken by mixing too many
> of our consensus concepts in the most inefficient manner.
> Here's my proposal...
> In 30 days, if there is no release of 2.5.0, we move /trunk/ over to the
> sandbox, and restore 2.4.x as the /trunk/.  No RTC, simply fix it, or if
> it is a complex change, propose it in that sandbox, in it's own sandbox,
> or to the dev list.
> If anyone wishes to start a clock on 2.5.0, they have 30 days to produce
> a release.  While our policy states they can do anything they like, the
> simplest history would be to start from 2.4.x trunk, append the patches
> from the sandbox 2.5 that they believe should survive, and tag and roll
> a candidate.  If rejected, no damage.  If accepted, that sandbox then
> becomes /trunk/ with /trunk/ relegated to /branches/2.4.x/
> More importantly, during the transition, the *RM* is responsible for
> keeping the sandbox in sync, not the entire body of httpd committers.
> I'm at a loss why a half dozen active committers need to do 2x the work
> to maintain a single branch.  And I have no question in my mind why it
> is down to nothing but a half dozen committers... the process and flow
> of the project is painful.  We could launch into a whole debate over the
> advantages of svn vs git, but the tool isn't the problem, it is the mess
> of process which we have created for ourselves.
> So my proposal to be presented shortly as a vote would be to abandon the
> trunk into a sandbox to be mined for good changes, once 30 days after a
> vote is concluded without a release, and to revert the 2.4.x trunk to
> CTR.  Comments and suggestions are welcome before I frame this as an
> actual policy vote...
> Cheers,
> Bill

View raw message