On 30 Jan 2003, Donovan Baarda <[EMAIL PROTECTED]> wrote: > On Thu, 2003-01-30 at 07:40, Green, Paul wrote: > > jw schultz [mailto:[EMAIL PROTECTED]] 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 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
