Setting up a Quality Team within KDE
Laszlo Papp
lpapp at kde.org
Tue Apr 10 04:45:17 BST 2012
> 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
More information about the kde-core-devel
mailing list