[Unison-hackers] a common patch set - first attempt [repost]

[Jerome Vouillon]

Hi all,

> 4) Reorganize the Unison repository and development process into  
> different branches -- "trunk", "stable", etc.  I'm reluctant to take  
> this path because it increases the overhead of making improvements to  
> Unison: we are still in a situation where very few people feel able to  
> make significant changes to the code, and I don't want to decrease  
> their motivation for doing so!
> 
> On the whole, I think doing either (1) or (2) would be an easy and  
> useful step over what we have now.  (3) is yet better but will take  
> time.  (4) I don't like much, but maybe somebody will convince me.  :-)

I'm in favor of option (4), and actually I don't really understand
what overhead you are talking about: improvements would be done in the
"trunk", just as now.

But I think the right question is what development model we want for
Unison.

For a long time, we had only one branch where both bug fixes and new
features were committed.  Also, we made few releases as it required a
lot of work.  I think this did not work that well, as it took a very
long time for bugs to be fixed in a stable release, and by the time
they were fixed, new bugs were also added.  (There was no bug
resulting in data loss though, which shows how well Unison was
designed by Benjamin.)

Recently, the package maintainers have started to collect the patches
I send to the mailing lists.  I did not expected that, but this seems
to work extremely well: some critical bugs has been fixed this way,
and the patches have introduced no new bugs nor compatibility
problems.  But this means that, as noted by Andrew, we are at the
moment in situation (4): we have a main trunk in the Subversion
repository and two additional branches 2.10.2 and 2.12.0 which are
maintained using patches.

This current situation is not very comfortable for me, as making
patches is a lot of overhead.  For instance, there are several bug
fixes in the developer version that I have not yet backported.
Committing a fix in a subversion repository would be a lot simpler
for me.

We could come back to a linear development process if we separated bug
fix periods (when preparing a new stable release) and improvement
periods.  But that seems a lot of overhead to me.

An additional point to consider is that it will be hard to maintain
the protocol compatibility without a lot of discipline from the
developpers.  This seems to be a argument in favor of having different
branches: a developpement branch where it does not have to be
preserved and some more stable branches for bug fixing where it must
be preserved.  Indeed, protocol compatibility is very easily broken.
For instance, just adding a new option breaks the compatibility.
Thus, the stable, beta and developer versions of unison are all
incompatible.  Actually, the beta and developer versions are almost
compatible: it seems there are only one small change that makes them
incompatible.  (It probably makes sense to revert it change, so as
to have an improved version of Unison which is still compatible with
2.12.0.)  But this is because I have mostly done some bug fixes and
polishing, and I refrained myself from making any modifications that
would also have changed the archive format.

-- Jerome