Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42DCDA2D.6020604@apache.org>
Date: Tue, 19 Jul 2005 12:47:09 +0200
From: Sander Striker <striker@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: [vote] Revoke R-T-C [was: svn commit: r219520]
References: <20050718155053.30446.qmail@minotaur.apache.org>
 <6.2.1.2.2.20050718115323.07e4b1c0@pop3.rowe-clan.net>
 <30145d9a5f5e3e84776c721bed376571@gbiv.com>
 <6.2.1.2.2.20050718130705.0b345230@pop3.rowe-clan.net>
In-Reply-To: <6.2.1.2.2.20050718130705.0b345230@pop3.rowe-clan.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> At 12:51 PM 7/18/2005, Roy T. Fielding wrote:
> 
> 
>>Or you could simply keep working on trunk like everyone else
>>and let releases be made when a tarball gets three +1s.
>>Version numbers are cheap.  Telling the entire group to stop while
>>you work on the next big patch is extremely expensive.
> 
> 
> Ok, so we are now three levels deep?
> 
>   /trunk
> 
>     C-T-R
> 
>   /branches/2.2.x  [misnomer, we don't have a beta yet]
> 
>     R-T-C ?  If not now, when?
> 
>   /branches/2.0.x
> 
>     R-T-C

There should be natural migration to 2.2.x.  2.0.x should be
considered closed for new features, that's what the development
line is for.
 
> Triple commits to fix one, one-line segfault?  Well, this isn't 
> workable.  I think lack of progress shows it's not workable.

The lack of progress is not due to having to commit to multiple
branches.

> Some of us, trawick, orton and myself come to mind, are still up
> for supporting our current users.

You make it sound like everybody else is dissing our current users.
This broad characterization is not exactly productive.

> As it is, backports aren't 
> reviewed, or committed once they are (I even split STATUS just to
> call out approved-yet-not-backported patches :-).  

The person who proposed the backport is expected to perform the
backport when it has enough votes.  The person casting the 3rd
vote sometimes does the backport.  And there are cases when a
friendly RM clears the slate when it comes to approved proposed
backports.

> Some were working on the stable release of 2.2.x, pquerna comes
> firstmost to mind.

It isn't just Paul who wants to see 2.2.x finally materialize.
We've been trying to get 2.2.x out for quite a while.  We've come
very close a couple of times, and because we like consensus we've
not pushed too hard.  I for one don't want to sit here again next
year and still discuss what needs to be fixed/refactored/whatever
before 2.2.x can be released.  Let's just move on.  2.2.x is already
a lot better than 2.0.x; our users deserve a release.

> Great progress is afoot, I see that release
> going beta very soon, the number of issues has dropped quite
> significantly.  [Although we have 29 PatchAvailable issues, not
> sure how many correspond to 2.2 commits not backported.]

> And others are yet working on 2.4.x.

2.3.x, leading up to 2.4.x.  As of the branch you are one of the
people working on that, what's the issue with that?
 
> So, I call a vote that we drop R-T-C altogether.  It's pretty clear
> to me that those interested in current / near-future / far-future
> users are almost three distinct groups.  It will be up to those
> small groups to call out and vote on changes within our individual
> domains.

Define current, near-future, far-future.

current == 1.3?
near-future == 2.0?
far-future == 2.x?

As it stands, only trunk should be C-T-R IMO.  Stability on the
_stable_ branches needs to be ensured.
 
> The question is; would we rather be saturated by commits we feel
> need review, or exhausted waiting for commits to be approved?

The latter, but again, it's a broad characterization.

> This means code might be committed to 2.0.x and never fixed in head,
> it might mean code is fixed in head and never considered for backport
> to our current users, but all in all, it beats the situation today.

No it doesn't.  trunk needs to be the branch that has the latest
code, and is most complete.
 
> I'm not suggesting that the 2.0.x users would entertain a break to
> ABI compatibility.  But I'm suggesting that parallel development
> doesn't work when most folks are focused on tangential development.


Sander