Hi all: On 11/7/07, Andrea Righi <[EMAIL PROTECTED]> wrote:
> it seems that someone is agree with me and someone is not about the solution > to > add the pre-release of rsync (3.0.0pre4) into the stable branch of > SystemImager > and tag the new 4.0.2 stable ASAP (4.0.1, since ".1" is odd, is reserved for > development pre-releases). I'm the 'someone' who does not agree with this :-) The main reason being rsync is a key component of SystemImager, and using a pre-release version (and mind you, a huge jump from 2.6.8 -> 3.0.0) which has not been fully tested would bring the stability of the release into question. Sure, 3.0.0pre4 might fix this particular problem, but without full testing we will not know whether this brings about _other_ issues that might be missed by both rsync and systemimager developers/users. > So, probably this is the first polling in these lists :-), don't know, but I > would really like to know opinion of the community about this issue. > > The fact is that the current stable release of SystemImager 4.0.0 is not > "stable" enough: there is a bug that occurs with rsync when it's built on a > machine with a kernel >= 2.6.22 (that's actually my build server) and the > installing client uses a kernel < 2.6.22: > > See http://www.systemimager.org:8000/trac.systemimager.org/ticket/6 for > details, > many thanks to Rochus Schmid for reporting this bug. > > The proposed solutions for now are: > > 1) use the pre-release of rsync that seems to fix the problem and tag > SystemImager 4.0.2, leaving the 4.0.0 packages as they are, let me say that I > would just proceed like the kernel guys do if there's a bug in the kernel > (just > leave all the previous released kernels "forzen" and available for download in > any case, and always release new versions in case of errors/bugs) > > 2) remove the old 4.0.0 packages from SF.net (let me say "close" them to the > users), rebuild all the packages in a build server with a kernel < 2.6.22 and > then release the new packages using the same version number: 4.0.0 > > 3) rebuild the packages in a build server with a kernel < 2.6.22 and changing > the version number to 4.0.2, leaving 4.0.0 packages as they are on SF.net > > 4) other ideas are welcome... > > I vote for 1). Okay, this is my suggestion: Since 4.0.0 is already released, we should just leave it. I do not feel strongly either way whether we decide to hide this release or not, but one argument for hiding it would be that the binaries are broken for users running Kernel < 2.6.22 (which I would think are the majority of the users). I wouldn't want a new user to somehow stumble upon the link for 4.0.0 and download something that does not work. My suggestion would be to increment the version number (for no particular reason than to keep it distinct from the bad 4.0.0 release) and simply rebuild all the files on a server that is running Kernel < 2.6.22 (RPM, deb etc.) and (re)-release that. I also think it would not be unreasonable to postpone the release until we can get some more testing done -- let's call this beta, and then after getting some more testing, we make the release. I would like to take this opportunity to invite the community to help us grow the project. The developers have put in a great deal of time and effort into adding new features and as we support more features and distribution/versions etc., we really need more volunteers to help us test the software before we release it. This will ensure that our code is as stable as possible prior to release. For argument's sake, I will call this solution b) :-) I'd like to cast my vote on b) Cheers, Bernard ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ sisuite-users mailing list sisuite-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-users
