httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject [vote] Revoke R-T-C [was: svn commit: r219520]
Date Mon, 18 Jul 2005 18:19:54 GMT
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?



  /branches/2.2.x  [misnomer, we don't have a beta yet]

    R-T-C ?  If not now, when?



Triple commits to fix one, one-line segfault?  Well, this isn't 
workable.  I think lack of progress shows it's not workable.

Some of us, trawick, orton and myself come to mind, are still up
for supporting our current users.  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 :-).  

Some were working on the stable release of 2.2.x, pquerna comes
firstmost to mind.  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.

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

The question is; would we rather be saturated by commits we feel
need review, or exhausted waiting for commits to be approved?

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.

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.


View raw message