Some questions about strace workflow.

[Dmitry V. Levin]

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 <cba840910 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160315/f4eae911/attachment.bin>