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
