<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'Sans Serif'; font-size:12pt; font-weight:400; font-style:normal;">Op maandag 23 november 2009 17:27:40 schreef Gunnar Wrobel:<br>
> [snip]<br>
><br>
> As pointed out by both Sascha and Bernhard before I also don't think <br>
> that building the packages is our core problem. Let me try to explain <br>
> why and then come back to the core problem we see: testing the server.<br>
><br>
> The openSUSE build service is of course interesting. It would provide <br>
> one piece of a continuous integration setup - where code commits <br>
> directly lead to an updated server release that could be tested. Using <br>
> something like the openSUSE build service would help in producing <br>
> releases for several platforms simultaneously. Compiling these for <br>
> several distributions would certainly help the package quality.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>I only mentioned the build service, as the OP wrote that someday maybe a shift from openpkg could happen (or not). If that will take place, it is interesting to have a look at the build service. The build is more much more than a service that build packages for different distributions, distribution versions and architures. It is a collaboration service. Packagers can easily work together to build packages, just like code version systems allow branches this thing allows branches as well. I'm using the service quite long and very often I'm surprised how well it works. It's difficult to explain if you have not worked with it, so I'm not going to do that.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>As all of you say, testing is important but at the end of the testing phase code is waiting to be delivered and most likely it will be delivered via a package... And this is also true for the testing suite.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>If the Kolab Konsortium wants to shift away from openPKG, it will pick one other distro, with a long term contract (SLES, Ubuntu LTE, RH, CentOS, etc). The disadvantage might be that not all hardware platforms are supported, but that is something that will probably be overcome. Test on that distribution and provide a rock solid groupware server. If now the packages are build in the build services (which could be hosted on e.g. build.kolab.org, just like cvs) for that distribution, other packages could be build from the same sources and spec files at the same time. Of course without the guarantee that it will work flawlessly, the community has to take care for that. Will that happen I can't tell, is it the best solution, don't know. It is just an example of what is possible.<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p>-- <br>
Richard<br>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;"><br></p></body></html>