On Mon, Mar 14, 2016 at 02:10:35PM +0100, Philippe Ombredanne wrote: > On Mon, Mar 14, 2016 at 2:25 AM, Yun-Chih Chen <cba840...@gmail.com> wrote: > > Hi strace developer, > > > > This is Yun-Chih Chen, a sophomore from National Taiwan University > > who is eager to tackle the "Multi-OS and multiarch continuous tests > > infrastructure" topic of this year's GSOC. Ever since my last > > proposal to the mailing list, I've been having some progress in > > solidating a solution. But I'm stuck at some questions listed below > > and I need your assistance: > > > > 1. Why do we need to test strace on multiple Linux distro, which > > run the same kernel? I understand that different Linux distro have > > different package base, different directory structure, etc. But since > > strace has few dependency and simple build flow, are the differences > > relevant to us? > > There are some differences beyond the kernel: different C libairies > (GNU Libc, uClibc, bionic, ...) and different compilers (GCC, clang, ...). > So testing on various distro is a sanity check to ensure that > various combos of OS/libc/compiler are decently working in > addition to multiple architectures. > > > 2. What is strace's current development cycle? Is it something like: > > Local development --> Run local test --> Push to Github + > > SourceForge > > --> Pull request --> Trigger Travis CI --> Run Codecov > > --> If everything is fine, merge into chunk > > --> ( some time later ) roll out a new release and push > > *.tar.xz to SourceForge > > --> Maintainers of the strace package on Debian, > > Archlinux, etc will pull the update from sf accordingly. > > The flow is rather: > Local development --> Run local test --> submit patch to the list. > Patches are then reviewed and discussed on list. > And possibly accepted and applied by the strace maintainer (Dmitry). > Dmitry pushes to his Sf.net repo branch which is mirrored to Github. > This eventually triggers some CI build on travis or elsewhere. > > > It seems that the responsibility of this GSOC project is not only > > making sure strace builds + runs smoothly on multiple platform, but > > also coming up with a suitable workflow to speed up testing + > > deployment. > > Automating the running of the tests is indeed part of it. > > As for the way things work overall, there is no plan to change things > as far as I know. When we met at FOSDEM, Gabriel, Dmitry and I > discussed Github and pull request: the feeling was that while this > has some good things for it, there are not enough benefits yet to switch > away from mailing list + patches. > That said, GH pull requests may be something to use at times for early > and/or larger patches review especially for GSOC contributions and as a > supplement, but not as a replacement for the mailing list. > Dmitry: is this a faithful report?
Yes, Philippe, thanks for the neat summary. -- ldv
pgp3Bzr1NRS_n.pgp
Description: PGP signature
------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
