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

[Martin Pool]

On 30 Jan 2003, Donovan Baarda <abo at minkirri.apana.org.au> wrote:
> On Thu, 2003-01-30 at 07:40, Green, Paul wrote:
> > jw schultz [mailto:jw at pegasys.ws] 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.
> [...]
> 
> After reading arguments, is support the "delay the branch till it
> absolutely must happen" approach... ie don't branch until a bugfix needs
> to go in to a "stable" version and HEAD is way too "unstable" to be
> released with the fix as the new "stable".

Yes, that is generally a better approach.  Remember, you can always go
back and create a branch from the release later on if such a situation
occurs.

Personally, I'm more interested in eventually starting from scratch
with something like duplicity, rzync, or superlifter.  I think the way
Subversion builds on the experience but not the code from CVS is
pretty good.  

Obviously there are downsides to this approach: it may be a long time
before the code is ready, and people may not want to switch for a
while after that.  But it may be more fun, and eventually yield a
cleaner solution.  I hope other people are interested in continuing
work on librsync and projects based on it.

I think the parallels between rsync and CVS are actually reasonably
strong: 

 - good tools, and de facto standards both for the free software
   community

 - showing signs of age in underlying assumptions (file-by-file
   versioning in CVS, shared filelist in rsync)

 - knotty code and interface that are a bit hard to refactor

 - most existing users have it working properly and don't *want*
   disruptive changes, just bug fixes or perhaps small additional
   features

 - new approach offers substantial benefits

 - doing something new is not urgent

All the above is just for me personally.  Continuing to move rsync
itself forward as and when appropriate is still a good thing.

> Actually, a bigger "attitude" issue for me is having a separate
> rsync-devel and rsync-user lists. I have almost unsubscribed many times
> because of the numerous newbie user questions;

Me too.

Samba does this with samba-technical and samba.  I think at this point
the user list for samba only has slightly more traffic than rsync.  I
think apache may now be the same too.

Plenty of people post user questions to samba-technical despite
prominent notices that it is only for developers.  They tend to both
piss off developers and go unanswered at least some of the time.  It's
probably due both to "my question *is* technical" and "if the
developers read it they might answer."  I'm not sure what a good
solution would be: probably a clearer name would help.  Perhaps
rsync-dev?  

What do people feel about this?

> I'm only interested in the devel stuff. I'm sure there are many
> users who have unsubscribed because of the numerous long technical
> posts.

-- 
Martin