2017-12-01


Highlights

  • Migration of projects (repositories and issue trackers) to GitLab is in progress
  • Release management: the TC converges on the idea of creating a REST API, if possible integrated in GitLab

Participants

  • Daniele Gagliardi DGA
  • Martin Hamant MHA
  • Stéphane Laurière SLA
  • Assad Montasser AMO
  • Benoit Mortier BMO
  • Clément Oudot CLO

Minutes

GitLab migration

  • Several projects were migrated successfully, in particular SAT4J, LLNG, ASM
  • GitLab has been upgraded

Management of releases

  • We have 4 main options so far: a) Nexus, b) SFTP/LDAP, c) Usage of webhooks, d) Own REST API
  • + option e) but probably not viable, involving storing a private SSH key in the project's secret variables : https://gitlab.com/help/ci/ssh_keys/README.md
  • DGA reminds everyone that we should focus not just on functional requirements, but also on non-functional requirements, as usability, security, scalability and measurability concerns, in line with the OW2 initiatives. Metrics include download stats, quality metrics, number of releases, etc. To be specified.
  • BMO claims the download metrics can be computed through an integration with Piwik.
  • MHA emphasizes that the ultimate solution would be to complete a merge request for https://gitlab.com/gitlab-org/gitlab-ce/issues/25533
  • CLO mentions the need, on LLNG side, to associate files to a release (tag) - which is part of the requirements indeed.
  • MHA reminds the GitHub release API at https://developer.github.com/v3/repos/releases/
  • BMO is in favour of implementing the REST API as sketched by MHA at https://tc.ow2.org/bin/view/wiki/File+Release+Management+Specifications
  • MHA emphasizes it is really interesting added value for OW2 as it closes the project lifecycle topic. OW2 would not only drive and host projects, but also provide a release management process, which is tied to the release management policy.
  • MHA explains there is no relation between project's uploads and tags, but the markdown links in the release notes.
  • DGA mentions that while we are moving from GForge, but we shouldn't have regressions.
  • MHA notes that GForge's file release system brings a structured design for releases.
  • In BMO's view, GForge is a mess and releases are not correctly managed.
  • MHA suggests that the OW2 management gets in touch with GitLab management to check if such a release API can be implemented via a sponsorship.
  • BMO believes that if we have a clear plan and some budget it should work.
  • DGA points out that it would be a great story to tell.

Action plan summary:
1) Check that it makes sense indeed for the OW2 management that we spend further time and resources on this aspect
2) Refine the API, draw inspiration from the GitHub API
3) See if we can negotiate the API implementation by GitLab with some OW2 financial support together with testing and documentation contributions

NB: see also: https://about.gitlab.com/development/