2018-07-13

Team Meeting

13 JULY 2018 / 11:00 AM / #ow2-tc on IRC, freenode

Agenda

Old forge decommissioning status
File release management early feedbacks
Needs for download statistics and other possibly useful metrics for projects
Next steps for TC

Participants

Daniele Gagliardi DGA
Martin Hamant MHA
Nicola Bertazzo NBE
Marc Chantreux MCH

Minutes

Old Forge Decomissioning Status

MHA: Old Forge decommissioned. Old server still online, but the service was shutted down last friday. Production services are on VPS, hosted at XSalto. Jira was stopped too.
MHA: recap an overview on infra: At ikoula (CloudStack) some VMs (for instance STAMP project VMs)
DGA: time to update https://www.ow2.org/view/IT_Infrastructure/ page, to reflect last infra changes
DGA asks about how many projects moved from old Forge to Gitlab
MHA: just 10 projects. Other projects have mirroring activated from Github. 10 projects have published their artefacts in OW FRM system (https://release.ow2.org/)
DGA: needs for project info within Gitlab?
MHA: projects are on https://projects.ow2.org/, and are in Gitlab too, being as mirror or native
MHA: OW2 guidelines are that every project should have the source code and documentation hosted at OW2.
DGA: github mirroring should be enough
MHA: anyway OW2 guidelines aren't published anywhere: need for consolidate and enforce it (page: https://tc.ow2.org/bin/view/wiki/OW2+Projects+Policy) Anyway we don't need to be strict as Apache, for instance (https://apache.org/legal/release-policy.html)
DGA: let's start simple

FRM Feedback

MHA: FRM just works. Not much projects are using it. Enabling it for a user requires admin attention for setup (manual process)
DGA: should we look for automation?
MHA: at the moment it isn't necessary. Anyway automation <> self-service

Project metrics

MHA: priority is OSCAR (add services: generalize sonarqube, scancode, STAMP) and platform documentation revamp
DGA: let's start with OSCAR
MHA: needs for adding services tools to Gitlab CI and collect metrics
DGA: for metrics we can leverage Nicola Bertazzo's experience
MHA: OSCAR metrics are based on xwiki pages, fed automatically by tools. Need for covert current XML code in Java plugin (to enhance mantainability)
NBE: I helped the development of old OW2 website
MHA: we have also Assad on board. Nicola can help to develop xwiki plugin
DGA: what about download metrics?
MHA: multiple sources: FRM and OW2 repository. We can leverage Matomo

Misc

MCH asks for who is who and a draft of current infra (plans, etc)
MHA introduces Nicola and Daniele
MHA asks which kind of info he's interested in
MHA asks for using STAMP tools within OW2 infra (but time is run out, the meeting ends at 12:30)

Some info on possible STAMP exploitation within OW2 infra:

DGA: STAMP tools have different functionalities that can be used in different stages of the project. We (ENG) are leading integration activities in order to let STAMP tools available as Maven plugins, Jenkins plugins, etc...
DGA: In STAMP you have three/four features:
DGA: 1. "test your tests": STAMP change your source code at runtime ("mutate" it) and execute your test cases in order to check their effectivenss. This tool is called Descartes, and implement the concept of "Extreme mutation testing"
DGA: 2. "amplify your test cases": STAMP generates automatically new test cases (JUnit test cases, actually) starting from the existing ones, in order to enhance the coverage and the ability to detect "mutations" (see point 1);
DGA: 3. "amplify your test configurations": projects which use Docker images to define test environments (i.e. which web server, which app server, which database, which thread pool size, etc) can use STAMP to generate new test configurations starting from the existing ones, in order to cover much different configuration scenarios. STAMP generates these new scenarios, and then execute project test cases against them. The STAMP tool which does this thing is CAMP
DGA: 4. "generate automatically a new test case able to reproduce a crash which occurred in production": when a crash occurs in production, usually you have a stacktrace in production logs. In order to fix the bug you need to reproduce the crash to perform the root cause analysis (what did get wrong?): usually this is the hard part. Evocrash (another STAMP tool) is able to generate a new test case, analyzing the log against the source code.
DGA: I think STAMP tools can be used remotely (it's one of the integration objectives) as REST microservices, and this can be a service OW2 infra can offer. STAMP tool 1 can also be used to generate metrics about projects test cases effectiveness, showing metrics such "mutation coverage" additionally to "code coverage"
DGA: This is a summary about STAMP possibile usages within OW2 infra.
DGA: Would be provide CI/CD services to projects, then we could integrate them with almost all the STAMP tools, at least tools 1, 2 and 3 (tool 4 in my point of view is much more a tool to investigate things rather than executing it automatically, but I could be wrong)