TC Meeting - 6 October 2017


Participants:

  • Eric Bruneton (EBR) by mail
  • Andre Freyssinet (AFR) by mail
  • Daniele Gagliardi (DGA)
  • Martin Hamant (MHA)
  • Stéphane Laurière (SLA)
  • Benoit Mortier (BMO)
  • Clément Oudot (COU)
  • Jean Parpaillon (JPA)

IRC log: tc-20171006.txt

Migration to GitLab

  • SLA reminds everyone that the migration consists of 4 parts: 1) Code repositories, 2) Issues, 3) Websites, 4) Releases.
  • EBR is satisfied with the migration of the repository and of the issues (ASM project).
  • MHA mentions that the JIRA field "Fix Version(s)" has been implemented in the JIRA issue converter as the "Milestone" field in GitLab.
  • MHA explains that the import of JIRA contributing users has evolved: now the contributors are added to the group of the project, not to the project itself, with access rights corresponding to the roles they had in JIRA: owner, developer or guest.
  • MHA points out that the current version of GitLab is now 10+ while we're running version 9.2.2. MHA and DGA recommend not to update GitLab until the migration is over because of API and data structure changes which would break the process, agreed.
  • BMO reiterates its recommendation to use GitLab, described as a great forge with lots of nice fonctionalities and a CI / CD much easier than Jenkins.
  • MHA raises the question whether we need to keep old projects in an SCM. An option would be to archive the old repositories as static compressed files.
  • AFR emphasises it is important that the migration procedures are well documented and that the migration effort is not too important.

Commits import

  • An issue is pending regarding the back references of commits from issues: when importing a commit referencing an issue, the issue does not provide a link to the corresponding commit. The linking works well for new commits though.
  • The problem is considered as not blocking by the participants, even though it would be a nice to have.
  • It remains possible in theory to parse all the commit messages and to include the back references as comments to the relevant issues.
  • BMO recommends to have a look at the contributed code handling the Redmine to GitLab conversion. MHA explains that the problem is different since Redmine stores commit <-> issues references, while in the OW2 case we don't have those references in JIRA since Fisheye is not running anymore.
  • The other projects using JIRA are AuthzForce and SAT4J, they will be polled.

References:

Websites

  • The natural option would be to use GitLab pages for the projects websites, using the dedicated domain ow2.io.
  • BMO: OpenSides is not using GitLab pages yet but BMO is in favour of it, considering all the fonctionalities of GitLab should be used, without the need to deploy and maintain other tools when the features are provided by GitLab. BMO points out that improvements require sometimes important changes, and that he kind of forced the migration to GitLab on their side to make it happen.
  • MHA is in favor of GitLab pages, but he emphasises it means a lot of migration work for existing websites.
  • DGA mentions ENG will use GitLab pages in the future, DGA will take care of the SpagoWorld family.
  • DGA emphasises the need of a well defined migration process, so as to provide guidelines to all the project leaders.
  • EBR: the management of project web sites is an important next step. Visually, it would make sense to allow projects (if they want) to use the same styles (fonts, colors, etc) as the OW2 site itself.

References:

File Release Management System (FRS)

  • MHA: SFTP could be an option, based on POSIX groups from LDAP. The projet manager would connect and get a list of project folders, with the permission to write in the folder owned by the project's group.
  • MHA has some remarks about the FRS but since time is lacking he will detail them on GitLab.

References:

Tracking down the TC activity

  • DGA suggests to set some tasks on a tracker in order to speed up the TC activities, through a dedicated project in GitLab as we had in JIRA (same approach used in STAMP also).
  • BMO seconds this approach, explaining that the FusionDirectory team has an infra group in GitLab, using templates to streamline the process [1], so that contributors fill in the same needed information.
  • DGA explains they have this approach in JIRA, with a corporate instance configured in a very detailed way to track activities and issues. DGA suggests we start using the default template, and if we realise to store additional info, we can consider to set up a template.
  • SLA takes note and proposes to create a Technology Council project in the OW2 public group [2].

References:

Marketplace / UForge

  • SLA reminds everyone that we have a free license of UForge which can let us create multi-cloud images.
  • BMO states that UForge is not useable for him, considering it slow and buggy, and that what is needed is a simple and straightforwad process with little work. Docker integration with GitLab is what they use for application delivery. BMO points out that there should be no human interaction in the process, only a pipeline delivering troughout continuous integration.
  • MHA remarks that it would be useful to know more about the typical use cases of the UShareSoft customers.

References:

Voting system

  • MHA points out a specification document would be useful to look for the most appropriate tool.
  • BMO explains there is a tool that emerged from Liquid Democracy, he will look for it.

Next meeting

  • Fri. 3 Nov. 11h-12h CET