I agree with what Bernard says here: rebuild 4.0.0 asap so users with kernel < 2.6.22 aren't bitten by the bug.
As for rsync, I am not sure I followed but is it a bug in rsync generally that is fixed in 3? Since rysnc is generally supplied by the linux distribution separately, I would not like to see SI require something that will conflict with what is provided by the base system. That's a headache and will just leave a lot of users back at SI 3.9.x until their distro goes to rsync 3. For fedora (which we use), that means a new release (at least f8, maybe f9) as they would not put it into an existing release as an update (if I understand the policy, and the policy is why we use fedora). my 2c, Patrick On 2007-11-7 15:53, Bernard Li wrote: > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/sisuite-users -- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.) ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-users
