Proposal that we now create two branches - 2_5 and head

'jw schultz' jw at
Thu Jan 30 09:50:34 EST 2003

On Wed, Jan 29, 2003 at 03:40:36PM -0500, Green, Paul wrote:
> jw schultz [mailto:jw at] wrote:
> [general discussion of forthcoming patches removed]
> > All well and good.  But the question before this thread is
> > are the changes big and disruptive enough to make a second
> > branch for the event of a security or other critical bug.
> Agreed.
> > Personally i doubt that such a bug is that likely to emerge
> > and that if it does we can always create a branch off of
> > the 2.5.6 tag at that time.
> Quite true.  But I'd like to make the point that I think it is worth making
> the decision to split now.  Having two branches will change attitudes.  And
> I think with as large a community of users as rsync clearly has, it is worth
> changing attitudes.  Having a production branch will remind us that we have
> a place to put stability or security fixes, and will make it easy to do so.
> Perhaps too easy; time will tell.  I'm concerned that if we wait until we
> clearly need a production branch, we'll probably have already forgotten to
> apply some fixes that should have also gone in, and then we'll be busy
> trying to grab them out of the cvs repository.
> I think if you look at this from a developer or maintainers point of view,
> having an extra branch is a pain.  A minor pain to be sure, but still a
> pain.  But if you look at it from a user's point of view, it is a very good
> thing...

I'm doubting that we really have an attitude problem here.
I don't discount the possibility of a critical bug being
discovered but the code is much more stable and is smaller
than other higher-profile projects.  Everyone responsible
for maintenance is an actual user and is living the user's
point of view.  We want the releases to be stable and

I'm concerned about patches getting into the "production"
branch that don't get forward ported.  Further, most of us
are using a CVS head so a critical patch will actually
be harder to generate as these diverge.  Divergence itself
could become an impediment to the release process.

I know what i'd like to see is a release rate that matches
the change rate.  Keep the main tree stable enough for
regular use and _if_ a critical bug appears we can decide
whether to back-port it for a maintenance release or
accelerate a normal release.  What i don't want to see is a
slowed release cycle just because there is a "stable"

This is CVS, we can always extract a tagged version.  One
thing we could do is to establish intermediate safe-point
tags just prior to applying disruptive patches so that if we
need it we can easily branch or roll back.


Thanks for bringing up the idea.  I may be mildly opposed to
it but would rather see it discussed than not.  We need to
keep the non-developer user's perspective in mind and keep
what is in their hands as current as may be reasonable.
These discussions serve that purpose and remind us what
perceptions may be.  If we can achieve a concensus on this,
wonderful.  If we branch now either by concensus or because
of stronger feeling by a few, OK.  For that matter, we can
try branching now and see if that helps.  Until someone
decides a given fix is critical and applies it to the
production branch, that branch won't make any difference
anyway and we can review it next release.  Mainly, i think
it is an issue that should be decided by those who do most
of the commits and especially whoever will take up the task
of the next release.

	J.W. Schultz            Pegasystems Technologies
	email address:		jw at

		Remember Cernan and Schmitt

More information about the rsync mailing list