From: Kern S. <ke...@si...> - 2011-01-26 22:37:11
|
Hello, If you are a beta tester or a regression tester, now is the time to start running your nightly regressions for version 5.1 (in the Source Forge git repo branch "Branch-5.1") and posting the results to our cmake dashboard. If you would like to do beta testing, now is the time to start testing, but for the moment, I do not recommend putting Branch-5.1 into production. We are now starting to stabilize it, and only have one or two more features to add, testing to do, documentation to prepare, an in about a month (hopefully a maximum of two) it will be ready for release. In the Bacula survey one user asked for a lot more and better beta testing, so now is the time to help out :-) We particularly need testers for systems other than RedHat 5/6 and other than Ubuntu -- for example, Solaris sparc, Solaris i86, OpenSolaris i86, FreeBSD, ... Instructions for doing automated regression testing are in the README in the "regress" directory, and more detailed document is in the Developer's guide on the web site. Best regards, Kern |
From: John D. <dre...@gm...> - 2011-01-26 22:46:57
|
> If you are a beta tester or a regression tester, now is the time to start > running your nightly regressions for version 5.1 (in the Source Forge git > repo branch "Branch-5.1") and posting the results to our cmake dashboard. > CMake dashboard? Are you using cmake now to generate makefiles and visual studio projects? John |
From: Kern S. <ke...@si...> - 2011-01-27 07:08:30
|
On Wednesday 26 January 2011 23:46:50 John Drescher wrote: > > If you are a beta tester or a regression tester, now is the time to start > > running your nightly regressions for version 5.1 (in the Source Forge git > > repo branch "Branch-5.1") and posting the results to our cmake > > dashboard. > > CMake dashboard? Are you using cmake now to generate makefiles and > visual studio projects? No, cmake is not yet available on enough machines by default, so we use make, but for the regression testing, we have it setup so we can use it with or without cmake. With cmake (actually ctest), it will post the results to the dashboard. Kern |
From: John D. <dre...@gm...> - 2011-01-27 11:01:24
|
> No, cmake is not yet available on enough machines by default, so we use make, > but for the regression testing, we have it setup so we can use it with or > without cmake. With cmake (actually ctest), it will post the results to the > dashboard. > Thanks. I remember a discussion from years ago about possibly using CMake in the future. My interest (as a programmer who uses CMake daily for 3 years on windows and gentoo linux) is that it would simplify the build process especially in the case of windows and also with the possibility to build bat with Visual Studio so that I could better debug why at times it crashes or becomes too slow to use on my network of 40+ clients and 30 to 50 TB of data currently backed up with bacula. I have read that there will be stability improvements on bat so maybe I do not need this. John |
From: Kern S. <ke...@si...> - 2011-01-27 11:16:28
|
On Thursday 27 January 2011 12:01:17 John Drescher wrote: > > No, cmake is not yet available on enough machines by default, so we use > > make, but for the regression testing, we have it setup so we can use it > > with or without cmake. With cmake (actually ctest), it will post the > > results to the dashboard. > > Thanks. > > I remember a discussion from years ago about possibly using CMake in > the future. > > My interest (as a programmer who uses CMake daily for 3 years on > windows and gentoo linux) is that it would simplify the build process > especially in the case of windows and also with the possibility to > build bat with Visual Studio so that I could better debug why at times > it crashes or becomes too slow to use on my network of 40+ clients and > 30 to 50 TB of data currently backed up with bacula. I have read that > there will be stability improvements on bat so maybe I do not need > this. Well at this time, we are not planning to use Visual Studio for building any part of bat or the Windows FD. We used to use it, but it is extremely time consuming and terribly prone to error when trying to build something because it requires a person to interface with a GUI, which is a guaranteed manner of introducing bugs. We script everything and build everything for Windows on Linux. We don't even need a Windows machine to build it. The process is a bit complicated, but is *far* less onerous than using Visual Studio (I can personally attest to that). The community builds of bat have not really been ideal because they have relied on building bat on the OS all of which have different versions of Qt. Unfortunately, different versions of Qt vary significantly, are often incompatibile and some are unstable. The Enterprise version of bat is *far* more stable, and the next version of the community release will be built the same way I am currently building the enterprise version at least for Windows and any platform for which the project supplies rpms. Note, bat on Windows is much more fragile than bat running on Linux systems due to the fact that Windows programming is inherently more complex than Linxu; and we rely on using Qt dlls built by Nokia rather than build them ourselves. Regards, Kern |