Tom Hacohen <tom.hacohen <at> partner.samsung.com> writes: > > Hey all, > > We recently released 1.0 for the core libraries, so now it's a good time > to review how we worked in the past, draw conclusions and hopefully also > improve our work-flow. When using the word "patches" in the following mail I > also mean commits done by developers with commit access (when that applies). >
Hey, all this is interesting. I just wanted to refresh your memories about a thread begun by vtorri iirc, suggesting an automated build system that would ease the 'no warning in patches' checking rule and more generally, anti-regression tests (at least for compilation at first). This thread was never finished, it did not seem to interest much people which is a pity since I believe most of you who experienced automated build farms at work, or in another project, would agree about its usefulness. Today quite a few solutions exist, including Jenkins (ex-Hudson, http://jenkins-ci.org), buildbot (http://buildbot.net) and all we need is a little time to put the infrastructure in place, and some machines around the world running different OSes so that we can give proof the libraries are cross-platform and still compile on exotic configurations that are only tested once in a while. Cross-compilation for ARM and so could be integrated too. My 2 cents, but I think it's an important part of making the workflow better. Let's automate. Lionel ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
