[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Summary from Buildsystem BoF at Desktop Summit
From:       "henry7638 () gmail ! com" <hank () millerfarm ! com>
Date:       2011-08-17 12:11:21
Message-ID: 36b08f25-abce-4756-881b-d40da521872f () email ! android ! com
[Download RAW message or body]

Very interesting, but it appears to assume all the world is linux x86 (these days \
probably x86-64, but the such VMs wouldn't run on any 32 bit machines that might be \
left). Many of our big problems are things that work fine there, but months latter \
someone gets around to doing that config on: ARM, PPC, or some more obscure \
processor; or it doesn't work on xBSD, Microsoft Windows, MacOSX, or one of the more \
obscure OSes we support. 

As such, I ask that everyone working on build systems consider how their solution can \
scale out to those combinations?  There are copyright problems with Comercial OSes \
(but windows machines are easy to find - thus a vm may not be ideal despite the \
simplicity of it)

Volker Krause <vkrause@kde.org> wrote:

> On Monday 15 August 2011 23:31:26 Alexander Neundorf wrote:
> > -----------------------------------------
> > 8) Testing
> > -----------------------------------------
> > 
> > We shortly discussed testing, continuous builds and nightly builds.
> > I hope Volker (or somebody) can write a better summary.
> > Volker has a prototype for easily running VM-based builds on
> Linux-machines,
> > which contribute their results to a cdash dashboard.
> > Marcus introduced us to cdash@home, which has a similar purpose, i.e.
> make
> > it very easy for people to contribute their machine as a
> continuous-build
> > host to a project.
> > It seems there is growing interest in establishing structured testing
> for
> > KDE, also highlighted by Till's talk "The limits of portability".
> > More details to come...
> 
> ok, so let me explain what I have been working on there.
> 
> The idea we came up with in Randa basically is to deploy more or less
> blank 
> Linux VMs in a SETI@Home-style to as many as possible machines. They 
> continuously run kdesrc-build with enabled CDash reporting as well as a
> script 
> to install new dependencies. All those scripts are regularly updated
> from Git, 
> allowing us to deploy updates to all VMs out there. The only exception
> is the 
> kdesrc-build config file, which is provided by a central server and
> downloaded 
> before every build run. This allows us to distribute different build 
> configurations to all VMs. Right now this config files simply
> randomized on a 
> number of parameters, giving us full coverage with a high probability
> over 
> time (with the time depending on the number of active VMs).
> 
> This approach addresses one specific problem of the entire CI topic,
> namely 
> testing as many as possible of the various different build options we
> have 
> (platform profiles, debug vs. release, different dependency versions,
> with or 
> without optional dependencies, etc). This does not address testing on 
> different OS/platforms etc., so it's only one piece in the puzzle, not
> the 
> single solution.
> 
> "Code" is in kde:scratch/vkrause/crowdci, the VM is created with SUSE
> Studio: 
> http://susegallery.com/a/8ECjUa/kde-crowdci. It still has some blocker
> bugs 
> that prevent it from installing extra dependencies without rebooting,
> so it 
> doesn't get past kdelibs yet, once that is fixed we can do a test
> deployment 
> and see if the approach works as intended. Help is of course welcome :)
> 
> regards
> Volker

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.


[prev in list] [next in list] [prev in thread] [next in thread]