Re: minutes of ESC call ...

On Fri, Jul 14, 2017 at 11:34 AM, Michael Meeks <michael.meeks@collabora.com
> wrote:

> * SSRLabs Interns (Michael)
>     + eight new hacking interns around: performance & quality
>     + starting on their first easy-hacks.
>     + Any ideas on quality ? (Xisco)

        + can write UI test; can take a couple.
>

So there is also one additional idea around that. I already started adding
some code that generates a log file with all the user interaction in the
hope of automatically transforming that data to UI tests (or automatic
replication of bug reports). So if there is a student interested in that he
could work on making sure that all the relevant information is in the log
file, writing a DSL (domain specific language) that represents the
information and a script to automatically convert the generated log file to
something based on the DSL.

This can be combined with the task of writing UI tests and extending the UI
testing to some more complex cases. The huge advantage is that this is a
task that is quite self contained and the code is well maintained. Long
term having the ability to log what a user does in the UI and replay it on
a developer machine would provide some huge benefits for us.


    + Extending performance test-suite (Markus?)
>

So we have at least two features that I would like to see but both are more
web development related. The current perf.libreoffice.org already has the
ability to store a comment for a specific data point but this currently
requires manual execution of a shell script on the server. We should add a
front-end for this feature making it easy to annotate data points with
commits that caused performance changes.

The second feature that I think would be quite useful is to have the
ability to get kcachegrind results for a specific test case and build ID.
Currently there is no way to get useful info from the scripts and it is
quite painful to debug performance problems. the VM is mostly idle during
the European night and could produce the required data. This might also
make it easier for QA and related fields to get good (symbols build,
correct callgrind config) callgrind output. Obviously this requires some
additional concept work.

All in all we can easily keep one student busy with some work here. The
work would be mostly python, scripting, html, js work. The advantage is
that it is a fairly contained project and a student will not need that much
introduction time.

    + XML filter pieces (Michael)
>         + continue & expand Azorpid’s work.
>     + other misc. threading / perf. Ideas (Michael)
>     + UX pieces (Heiko)
>         + problem is: need a coding mentor here.
>         + missing table styles, area style types etc.
>         + page background etc.
>     + build performance on windows ? (Thorsten)