Some questions about strace workflow.

[Philippe Ombredanne]

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?

-- 
Cordially
Philippe Ombredanne