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

[jw schultz]

On Wed, Jan 29, 2003 at 10:41:40PM +1100, Donovan Baarda wrote:
> On Wed, 2003-01-29 at 18:22, Craig Barratt wrote:
> > > I have several patches that I'm planning to check in soon (I'm waiting
> > > to see if we have any post-release tweaking to and/or branching to do).
> > > This list is off the top of my head, but I think it is complete:
> > 
> > And I have several things I would like to work on and submit:
> > 
> >  - Fix the MD4 block and file checksums to comply with the rfc
> >    (currently MD4 is wrong for blocks of size 64*n, or files
> >    longer than 512MB).
> 
> I'm interested in contributing to this effort too; I have helped fix and
> optimise the md4sum implementation for librsync. Once the issue of
> protocol backwards compatibility is resolved, this code could be dropped
> as is into rsync (up to 20% speed increase over current implementation).
> 
> However, I also want to change to using the RSA implementation API, and
> submit this code upstream to libmd (it has an optimised md5sum, but only
> the RSA md4sum). That way all the projects that used the RSA
> implementation could benefit from a more optimised md4sum (and can
> contribute bug fixes etc).
> 
> >  - Adaptive first pass checksum lengths: use 3 or more bytes of the MD4
> >    block checksum for big files (instead of 2).  This is to avoid almost
> >    certain first pass failures on very large files.  (The block-size is
> >    already adaptive, increasing up to 16K for large files.)
> [...]
> > But before I work on these I would like to make sure there is interest
> > in including them.
> 
> IMHO adaptive checksum sizes is critical. People are starting to rsync
> partition images and the maths shows rsync degenerates really badly as
> file sizes get that big.

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.

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.

Related to this is that we should make an effort to
incorporate just one of these larger changes at a time
please.   If we have to increment the protocol version
number by two or three going from 2.5.6 to 2.5.7 that is OK
by me.

I am inclined to prioritize the checksum fixes.  They are
central to rsync and i'd like them to get a maximum of
testing as early in the new cycle as possible.  This is the
one scaling deficiency we have a decent chance of fixing.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt