[vote] Revoke R-T-C [was: svn commit: r219520]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

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

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
domains.

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.

Bill

Re: [vote] Revoke R-T-C [was: svn commit: r219520]

[Sander Striker <st...@apache.org>]

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

Re: [vote] Revoke R-T-C [was: svn commit: r219520]

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On July 18, 2005 1:19:54 PM -0500 "William A. Rowe, Jr." 
<wr...@rowe-clan.net> wrote:

> 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 :-).

Well, why haven't you backported them then?  Why are you looking for someone 
else to do the work?

> 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.

-1.  R-T-C is the crux of our stability pact with our users.  -- justin

Re: [vote] Revoke R-T-C [was: svn commit: r219520]

[David Reid <da...@jetnet.co.uk>]

-1

Re: [vote] Revoke R-T-C [was: svn commit: r219520]

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 01:19 PM 7/18/2005, William A. Rowe, Jr. wrote:

>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.

+1

just my own 2c.

Bill