Setting up a Quality Team within KDE

[Andreas Pakulat]

On 09.04.12 23:29:17, Laszlo Papp wrote:
> >> I will also try out this Jenkins in the future once I find the time
> >> for that, but I have been a happy CDash user for about ten months by
> >> now. :-)
> >
> > build.kde.org can give you a pretty good idea of how jenkins "looks" and
> > can be used to do CI.
> 
> I do not personally find the page aforementioned having that
> professional layout as the CDash site, but that might be just me.
> Also, I personally find the CDash site simpler to use.

I noted my personal impression only as a PS since I'm well aware that
there's much personal preference here. One thing I do like about
jenkins: I see the status of the projects immediately when opening the
page. With some better filtering/views set up this can be quite handy.

> My personal worry is that, I would not like to refactor the setup
> already existing and working just fine for a while unless there is a
> compelling reason and the switch is simple.

I'm not sure what exactly the setup is on build.kde.org, looking at the
console output some envvars are set and then as I said in another reply
all it takes is 

cd build && cmake ../ && make && make install

No further setup needed (unless the unit-tests have some specific
requirements). If thats encoded into the ctest script you could also
just run ctest.

> Also, I do not see Playground projects on the build.kde.org site.

The service is comparatively new, but as can be seen already has a lot
more builds on it then ever where done for CDash. Also IIRC there was a
blog-post inviting people to submit requests for the addition of their
projects.

I also don't see any KDE playground apps on my.cdash.org :)

> In addition, if it is just for KDE, it would result me using different
> services for Qt Playground and KDE projects. That would be a bit
> unhandy. I could use CDash for both.

If one is involved with different projects outside of Qt/KDE then its
quite normal to have to deal with various types of web-services. So
personally I don't think thats a good enough reason to ignore the
benefits that jenkins does provide.

In addition as was said elsewhere in the thread, the jenkins job could
submit their data to cdash too if the projects are set up for that.

> That having said, CDash was designed with CMake in mind. We already
> depend on CMake and CTest.

We actually do not depend on CTest, that is an optional tool, one can
run the tests without ctest (in fact I've never used CTest on my
machines).

> Those three projects are maintained by the
> same company, if I am not mistaken, called "Kitware" (and probably
> also by community volunteers). Therefore, we can be sure about the
> integrity and so forth. On the contrary I can somewhat understand the
> need for a community driven site even if it is quite unlike Kitware
> just goes away. They have not been doing that with cmake either for
> many years. They respect KDE, and Alex has always been very helpful
> with those topics. :-)

I'm not questioning the usefulness of CDash or wether the free-hosting
goes ever away. I don't actually care who hosts the CI-server for KDE
projects, all I care about is that its easy to get a project set up to
be build continously (and the unit-tests executed) and wether it
provides more than just build errors/warnings and test-results. Since
some of these things are handy - especially when working on libraries.

Andreas