Re: Proposal that we now create two branches - 2_5 and head
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. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: Proposal that we now create two branches - 2_5 and head
Martin Pool [mailto:[EMAIL PROTECTED]] wrote: On 28 Jan 2003, Green, Paul [EMAIL PROTECTED] wrote: I think splitting the branches will also let us be a little more experimental in the development branch, at least until we get near the next release phase, because we'll always have the field release in which to make crucial bug fixes available quickly. I agree that this would be a good approach if and only if there is energy to do lots of development in the head branch. What do you have in mind? (I've seen the replies from JW, Wayne, Craig, and Donovan, and just in those letters I see enough development activity to suggest to me that splitting is a good thing...) I'm working on a fix that will solve the temp file name is 10 characters longer than the original file name problem. The trick is coding this in a way that is POSIX-compliant and able to deal with simultaneous use of multiple file systems that might have different max lengths. PG -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: Proposal that we now create two branches - 2_5 and head
jw schultz [mailto:[EMAIL PROTECTED]] wrote: On Wed, Jan 29, 2003 at 03:24:57PM +1100, Martin Pool wrote: On 28 Jan 2003, Green, Paul [EMAIL PROTECTED] wrote: I think splitting the branches will also let us be a little more experimental in the development branch, at least until we get near the next release phase, because we'll always have the field release in which to make crucial bug fixes available quickly. I agree that this would be a good approach if and only if there is energy to do lots of development in the head branch. What do you have in mind? And if such development rendered the code sufficiently unstable that we couldn't safely release a new version for security patches, if needed. Hold on a minute. One of the major points in favor of splitting the tree is so that we will have a stable version in which we can apply security patches. Do you disagree, or am I completely misunderstanding you here? Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. Speaking from Stratus not for Stratus -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Proposal that we now create two branches - 2_5 and head
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. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
problem with option -n and empty directories
I have a problem using option -n (to test if a sync operation will be done) and I add empty directory in the source tree. If I make: # mkdir source/empty # rsync -n -v -a ... source/ dest rsync does not notes empty dir, but if I remove -n option it synchronize correctly also the empty dir. Why ? I think this is important because, as I do, a command like `rsync -n' could be inserted in crontab, for example hourly, to check if the source tree has to be updated. Please answer directly to me at [EMAIL PROTECTED] Thank you very much. Marco. -- % dott. Marco Broglia % Nsa srl, viale Regina Margherita 81, I-20050 Macherio (MI) % email: [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: [PATCH] open O_TEXT and O_BINARY for cygwin/windows
Dave Dykstra wrote: I suspect it's also the reason why the build.samba.org cygwin machine hasn't reported a result in the last 9 hours. Nope.. problems with the CPU fan-cooler =( I'm taking it back out and washing my hands of the cygwin rsync port, I'm fed up. I'll catch up with Max doscovering and do further testing after tomorrow's test. -- Lapo 'Raist' Luchini [EMAIL PROTECTED] (PGP X.509 keys available) http://www.lapo.it (ICQ UIN: 529796) -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: problem with option -n and empty directories
On Wed, Jan 29, 2003 at 05:31:59PM +0100, Marco Broglia wrote: I have a problem using option -n (to test if a sync operation will be done) Yeah, it's a known bug that -n doesn't mention everything that rsync would output if -n wasn't specified. I've also noticed that rsync sometimes does things _without_ -n with no mention either -- for instance, if it changes a file mode or an owner (but nothing else about the file) it doesn't output anything. This is something that we should look into fixing. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
rsyncd 2.5.6 still treats sysmlinks differently
With much hope I upgraded to rsync version 2.5.6 in hopes that it would correct the symbolic link bug I have been wrestling with... No dice. It still insists on dropping the leading slash from a symbolic link outside the source tree. Interactively it still works fine, but as a daemon it's busted. See previous posting 'rsyncd treats symlinks differently' for details. Can someone acknowledge this issue ? Is it a bug ? feature ? something else entirely ? Thanks -- Karl A. Wieman voice: 212-409-3371 Director, Technology fax:212-407-5697 BlackRock Financial Management Inc.e-mail: [EMAIL PROTECTED] Audacity is a virtue that should always be practiced with caution. - Walter Slovotsky -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: rsync 2.5.6 fails on Tru64 v5.0 with rsync://hostname/
Laurent CREPET [mailto:[EMAIL PROTECTED]] wrote: I've just compiled 2.5.6 release on Tru64 V5.0A (configure detects alphaev67-dec-osf5.0, gcc release is a 3.1.1). rsync fails using rsync://hostname/ syntax. lct@goliath(32) [rsync-2.5.6]$ ./rsync rsync://stitch/ rsync: getaddrinfo: stitch 873: servname not supported for ai_socktype rsync error: error in socket IO (code 10) at clientserver.c(83) Is there anyone else that has the same problem ? Apparently not. Did this work on this same OS in rsync version 2.5.5? PG -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: Proposal that we now create two branches - 2_5 and head
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. 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... 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. Agreed. Tho once we start fixing bugs in the new features things will get confusing again. 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. Agreed, except ... do we have any control over the order in which our volunteers submit their changes? Doubtful... Thanks PG -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: rsync-2.5.6 build on Red Hat 8.0 fails
Horst von Brand [mailto:[EMAIL PROTECTED]] wrote: The packaging/lsb/rsync.spec file is broken as shipped: It has a Sept month (rpmbuild here takes only 3-letter month names), and RH gzips the manpages, so the %files list can't find them. I also added doc/README-SGML and doc/rsync.sgml to the %doc files. Patch follows. Patch applied. Thanks PG -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.6 fails on Tru64 v5.0 with rsync://hostname/
On Wed, Jan 29, 2003 at 03:23:11PM -0500, Green, Paul wrote: Laurent CREPET [mailto:[EMAIL PROTECTED]] wrote: I've just compiled 2.5.6 release on Tru64 V5.0A (configure detects alphaev67-dec-osf5.0, gcc release is a 3.1.1). rsync fails using rsync://hostname/ syntax. lct@goliath(32) [rsync-2.5.6]$ ./rsync rsync://stitch/ rsync: getaddrinfo: stitch 873: servname not supported for ai_socktype rsync error: error in socket IO (code 10) at clientserver.c(83) Is there anyone else that has the same problem ? Apparently not. Did this work on this same OS in rsync version 2.5.5? No, 2.5.5 won't build on our Tru64 v5.0 system. Do you have a binary (2.5.6) to send by e-mail or that could downloaded on a FTP server ? Laurent. -- Laurent CREPET -- [EMAIL PROTECTED] http://megrapet.free.fr/ -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsync 2.5.6 fails on Tru64 v5.0 with rsync://hostname/
On Tue, Jan 28, 2003 at 09:24:26AM +0100, Laurent CREPET wrote: I've just compiled 2.5.6 release on Tru64 V5.0A (configure detects alphaev67-dec-osf5.0, gcc release is a 3.1.1). rsync fails using rsync://hostname/ syntax. lct@goliath(32) [rsync-2.5.6]$ ./rsync rsync://stitch/ rsync: getaddrinfo: stitch 873: servname not supported for ai_socktype rsync error: error in socket IO (code 10) at clientserver.c(83) Is there anyone else that has the same problem ? Try recompiling without getaddrinfo support: ac_cv_search_getaddrinfo=no ./configure ... -- albert chin ([EMAIL PROTECTED]) -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: configure issue (ac_cv_lib_inet_connect) on DYNIX/ptx
On Wed, 29 Jan 2003, Green, Paul wrote: Michael Sterrett -Mr. Bones.- [mailto:[EMAIL PROTECTED]] wrote: I also get this warning, which is trivial, but it would be nice to clean it up: cleanup.c, line 36: portability warning: trigraph sequence replaced Great, thanks. This is from the () in cleanup.c. To get rid of the warning, just remove the () from line 36. This is clearly within a valid C comment. Your tool is dull and needs to be sharpened. heh, I don't think anyone will tell you that the C compiler on Dynix/PTX is an example of a *good* compiler. ;-) I'm sure IBM will thank us when we're finally off this architecture. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: rsyncd 2.5.6 still treats sysmlinks differently
On Wed, Jan 29, 2003 at 02:34:43PM -0500, Karl Wieman wrote: With much hope I upgraded to rsync version 2.5.6 in hopes that it would correct the symbolic link bug I have been wrestling with... No dice. It still insists on dropping the leading slash from a symbolic link outside the source tree. Interactively it still works fine, but as a daemon it's busted. See previous posting 'rsyncd treats symlinks differently' for details. Can someone acknowledge this issue ? Is it a bug ? feature ? something else entirely ? Do you have use chroot = false set? If so, this is documented behavior. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: Proposal that we now create two branches - 2_5 and head
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. 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 [...] 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; 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. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Proposal that we now create two branches - 2_5 and head
On Wed, Jan 29, 2003 at 03:40:36PM -0500, Green, Paul wrote: 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. I think I see now how you're viewing this branch -- as something to keep updated with fixes in parallel with the devel trunk. I don't really think we need that at this point. I was thinking of it as a completely unused thing until we decided that we needed an emergency bug-fix release for a specific issue (and we didn't feel that the trunk was in good enough shape to make a new release in a short timeframe). So, I'm mildly against having this. Other projects have it because the changes on the trunk are radical enough that it will take too much time between bug-fix releases, and I don't think that's where we are with rsync at the moment. That's all IMHO, of course. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
RE: Proposal that we now create two branches - 2_5 and head
I agree with this. I am in a situation where I don't install rsync myself, I have to depend on sysadmins to do it. They get very nervous and insist on installing it as something like rsync2_5_5 because they are afraid some other users legacy rsync invocation is going to break; you can't blame them for their circumspection. They'll gladly install bug fixes, of course, but I can't say every few months hey could you install the new rsync because there's a critical bug fix tied in with a bunch of features any current user is unlikely to use. I'm sure just getting them up to 2.5.6 from 5.5 will be a bit of a pain. If I really NEED a new feature, but frankly between perl and the three hundred or so options that rsync now supports that seems unlikely, then I can petition them to do the upgrade; otherwise, why should they? Dave -Original Message- From: Green, Paul [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 8:14 PM To: Rsync Mailing List (E-mail) Subject: Proposal that we now create two branches - 2_5 and head I'd like to suggest that this is now a great time to create two separate cvs branches for the rsync product. One, which I'll tentatively call 2_5, would hold the version of the code that has been released to the world as 2.5.6. The other, which I'll tentatively call head, would hold the development activity leading up to the next field release. I'm not bound to these names, but I picked ones that are parallel to the names used in the samba tree, for simplicity and ease of communication. I won't go into a long involved explanation, because I think most people understand the tradeoffs. Briefly, I see the major benefit as giving us the ability to send out important bug fixes or security fixes to users of 2.5.6 without exposing them to experimental or lightly tested development activities. I think splitting the branches will also let us be a little more experimental in the development branch, at least until we get near the next release phase, because we'll always have the field release in which to make crucial bug fixes available quickly. It is a little more work for the maintainers, but I think the benefits far outweigh the costs. We can minimize the extra work by minimizing the changes to the released version. And if we can get agreement to do it, now is the best time, when there has just been a release. Comments? Thanks PG -- Paul Green, Senior Technical Consultant, Stratus Computer, Inc. Voice: +1 978-461-7557; FAX: +1 978-461-3610; Video on request. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: Proposal that we now create two branches - 2_5 and head
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
Re: Proposal that we now create two branches - 2_5 and head
On Wed, Jan 29, 2003 at 05:44:32PM -0800, Madole, Dave BGI SF wrote: I agree with this. I am in a situation where I don't install rsync myself, I have to depend on sysadmins to do it. They get very nervous and insist on installing it as something like rsync2_5_5 because they are afraid some other users legacy rsync invocation is going to break; you can't blame them for their circumspection. They'll gladly install bug fixes, of course, but I can't say every few months hey could you install the new rsync because there's a critical bug fix tied in with a bunch of features any current user is unlikely to use. I'm sure just getting them up to 2.5.6 from 5.5 will be a bit of a pain. If I really NEED a new feature, but frankly between perl and the three hundred or so options that rsync now supports that seems unlikely, then I can petition them to do the upgrade; otherwise, why should they? You bring up a good point Dave. There is a great deal of variety in how projects handle their version numbers. We all know the linux numbering scheme, other projects use a version.revision.patch where patch means only bug fixes. Rsync seems to be neither of these. In fact i'm not sure what the criteria would be to go to 2.6. Perhaps you'd like to distill from this thread and the list a draft release version numbering philosophy statement. Gack! What a lousy title for a document, sounds like something the PHBs would go for. Although there were a number of enhancements going from 2.5.5 to 2.5.6 even i, who wanted my feature in a release, consider it released primarily for the bug-fixes. By August there were just too many cases where bug reports were for things that had already been fixed. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: proposal to fork the list (users/developers)
On Thu, Jan 30, 2003 at 02:16:42PM +1100, Martin Pool wrote: On 30 Jan 2003, Donovan Baarda [EMAIL PROTECTED] wrote: [discussion of cvs branches and rsync successor projects] 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? Won't make much difference to me although i'm more inclined to leave it as is. As far as i can tell rsync is only getting around 100 messages per week. I'd most likely just have procmail drop both lists into the same box anyway. The bigest concern is that one of the lists would wind up mostly dead. Most of our newbies are good enough to read the manpage and play around a bit. Most of the bald-faced how do i use it questions are preemted by the website. A better how do i report a bug guide might help somewhat but otherwise i've been pretty impressed by the quality of the questions. The real issue is what rules to apply to the rsync-devel list if everyone else wants that. At a minimum we should probably require subscription prior to posting. So put me down as oposed to a list-split but only mildly. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: [trivial patch] link overloaded
On 29 Jan 2003, jw schultz [EMAIL PROTECTED] wrote: This is just a trivial documentation change. The word link is overloaded. It refers to symlinks, hardlinks and network links. When looking for references to file links in the manpages the network references get in the way. +1 -- 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
CVS update: rsync/packaging/lsb
Date: Wed Jan 29 20:52:59 2003 Author: paulg Update of /data/cvs/rsync/packaging/lsb In directory dp.samba.org:/tmp/cvs-serv17845/rsync/packaging/lsb Modified Files: rsync.spec Log Message: Apply fix from Horst von Brand. See comments in rsync.spec. Revisions: rsync.spec 1.3 = 1.4 http://www.samba.org/cgi-bin/cvsweb/rsync/packaging/lsb/rsync.spec?r1=1.3r2=1.4 ___ rsync-cvs mailing list [EMAIL PROTECTED] http://lists.samba.org/mailman/listinfo/rsync-cvs
