> Also IIRC there was a blog-post inviting people to submit requests for the > addition of their > projects.
I believe, I missed that. > I also don't see any KDE playground apps on my.cdash.org :) http://my.cdash.org/index.php?project=Gluon http://my.cdash.org/index.php?project=QtOpenAL (You do not find it in playground since it was deleted 1-2 days ago after migrating to Qt Playground, but it has been hosted there). Unfortunately, I had some server issues recently though that I did not have time to deal with. At any rate, playground projects should be able to have quality services on wish as well IMO. > 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. That is not so simple. Once you get used to the feeling and you settle down you can use the same service for multiple projects, it is a bit difficult to persuade yourself it is worth changing in order to have more services to get familiar with. Like I said, as for me, it needs to have a compelling reason with smooth transition and simple usage in the future as well. As for my case, I would not just personally like to get involved in two different services, if I am fine with one. > 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. :-) Meanwhile, I trust you it is possible to do that, I prefer to avoid the multilayering, if possible. >> 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). I stand corrected, you are right about that. You can use "make test" without getting involved with CTest. [...] > 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. Could you please precisely enumerate the technical pros and cons so that we can all understand ? Thank you in advance! Best Regards, Laszlo Papp
