On Fri, 20 Feb 2015 11:44:02 +0100 Holger Levsen <holger@layer-acht.org> wrote: > Hi Neil, > > On Freitag, 20. Februar 2015, Neil Williams wrote: > > Is there interest in people gathering for DebCamp15 with an idea of > > setting up something like lava.debian.net to cover these areas: > > > > Ideas and use cases for lava.debian.org (initially lava.debian.net) > > to act as a frontend to developer-based LAVA dispatchers behind NAT > > connections. (This part of the LAVA package is currently being > > designed and will be backported to Jessie once ready.) > > what is this lava stuff? https://packages.debian.org/jessie/lava-server Continuous integration system currently in use for kernel and bootloader testing on ARM but open to other architectures as well. It's automating the testing of software on real devices. The version currently in Jessie is being substantially re-written to make it a lot simpler to use for tests that organisations like Debian are likely to be interested in using. In particular, allowing developers with boards on their desks to contribute their results (and potentially allow others to run tests on those boards) without issues of complex setups or firewall changes. Bootloaders are still a bit of an issue in that the bootloader commands can be changed as part of any test but actually installing a different build of the bootloader requires extra hardware (as yet not fully functional) to support automation. However, this still allows, e.g. the default Debian build of a bootloader to be tested in multiple different deployments on multiple boards, all at the same time. Debian has a number of QA tasks based around individual packages but little support for QA tasks involving architectures other than amd64, tasks involving multiple packages interacting or disparate systems or reproducible testing of large scale upgrades. > > Debian Installer test parallelisation on x86 and ARM - utilise > > support from FAI to completely automate testing of DI, possibly > > including support for video capture cards (where hardware is > > available). > > FAI as in fully automatic install or something else? Yes, fully automatic install so that DI builds can be tested on lots of different devices at the same time, automatically. > > If there is sufficient interest and enough people likely to attend > > DebCamp, I would be willing to put this forward as a > > Sprint-looking-for-a-team.... > > I likely won't be there.... (but am still curious about the topic :) :-) What has become apparent within the LAVA usage is that LAVA is one piece of a solution for implementing CI in this way. Once the results are available, the data needs to be presented in a way that is relevant to one specific audience. Teams are now using LAVA as the data source and building custom frontends to be able to close the CI loop and get relevant information back to developers in as short a timeframe as possible, directly after commits or merges. e.g. http://kernelci.org/ So something like ci.debian.net could incorporate this data or another frontend could be designed which collates the raw LAVA data into a format suitable and meaningful to Debian folk. What I'd be looking for from a sprint like this is to create a team willing to work on providing this frontend and a collection of people willing to run tests on hardware already available. This would include devices which are currently available via Linaro, just as kernelci.org does. The sprint would also cover what kind of tests people want to run and how the results should be presented. The new dispatcher which would run the tests is in development and won't be complete by this DebConf, however, enough is expected to be available to allow initial design. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpsaxin1Ku8K.pgp
Description: OpenPGP digital signature