2017-11-10


Highlights:

  • The migration process from SVN + JIRA to git + GitLab is now working well despite minor issues.
  • We will reevaluate the GitLab built-in release feature taking into account the feedback provided by Benoit.
  • We will send a questionnaire to the OW2 project leaders about their interest in UForge.
  • The per-project Docker image registry available on gitlab.ow2.org will be used within STAMP.
  • We adopt CIVS as the new voting system.

Participants

  • Jesus Gorronogoitia Cruz YOS
  • Assad Montasser AMO
  • Benoît Mortier BMO
  • Martin Hamant MHA
  • Stéphane Laurière SLA
  • Alexandre Lefebvre ALE
  • Olivier Lizounat OLI

Agenda

  • Migration to GitLab
  • File release management
  • Marketplace / UForge follow up
  • New voting system

Migration to GitLab

  • LemonLDAP::NG has been migrated successfully from Subversion and JIRA to git and to the GitLab issue tracker [1].
  • A couple of issues remain:
    • The commits count is wrongly set to 1. Workaround: perform a commit from the GitLab UI.
    • The date of the back references from a commit to an issue is wrongly set to the one of the initial push. Example: [2].
  • Next steps: migrate the other repositories and issue trackers one by one, and post a blog about the JIRA to GitLab converter, announcing the availability of the code [3] under the same license as GitLab: MIT license.
  • YOS questions the reasons for moving from JIRA – the de facto tool in the industry – to the GitLab issue tracker. Brought answers: usage of open source software, getting everything in a common place and taking the most of integrated tools with an efficient API
  • Big up to MHA for the migration.

[1] https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/
[2] https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1245
[3] https://gitlab.ow2.org/ow2/gitlab-utils

File release management

  • Reminder of the pros and cons for Nexus and SFTP [4] and of a previous discussion [5].
  • BMO mentions they're going to make the first release of FusionDirectory with GitLab and are actively looking at the GitLab release management [6]. BMO is in favor of GitLab release management. He tends to prefer having the release done at the same place as the rest of the project.
  • Regarding stats, BMO found some reference about making Piwik work with GitLab: [7].
  • MHA raises several issues: modularity, scaling (mirroring), lack of any "release" tab: releases are only tags that are named "release-xyz"
  • BMO mentions that in his experience, people keep downloading from the official mirror even though there are others from several companies or institutes.
  • BMO is in favour of keeping things simple at first and considering possible scalability issues later on.
  • MHA emphasizes that if the downloads are available on gitlab.ow2.org/xyz, and all the links are spread over the Internet we will get extra work to change this to anything else.
  • BMO takes the example of GitHub: you see something, you go to the project, you read and download if wanted all from the same place and UI. It also allows to easily get back to older releases and see all the commits.
  • MHA mentions he's totally for using GitLab release management on its own but he's also thinking about the big picture.
  • SLA reminds the need to use an API to automate the release process.
  • Projects hosting their code elsewhere would create an "empty" GitLab project specifically for publishing the releases.
  • MHA reminds this shares some concern with the governance of OW2
  • We need to keep maintaining Nexus for managing Java artifacts.
  • ALE mentions they use Jenkins at UShareSoft and he will gather info about the CI/CD and release process.
  • BMO explains they're setting up a process for releasing everything out of the CI/CD.
  • BMO will post his findings about release management for FusionDirectory in GitLab to the technology-council mailing-list as soon as its finished.
  • MHA explains the OW2 GitLab instance supports a per project Docker image repository for CD.
  • YOS will use that feature in the STAMP context.

[4] https://mail.ow2.org/wws/arc/technology-council/2017-10/msg00008.html
[5] https://mail.ow2.org/wws/arc/technology-council/2017-01/msg00014.html
[6] https://docs.gitlab.com/ce/workflow/releases.html
[7] https://about.gitlab.com/2015/11/27/gitlab-switches-to-piwik-analytics-to-free-the-javascript/

Marketplace / UForge

  • Reminder of the use case descriptions provided by ALE, adressing also usability issues: [8].
  • According to BMO, with GitLab and Docker you get a direct deployment of a demo instance for example.
  • ALE explains that the purpose of the AppHub Factory was to make available a working installation of the software inside a working machine. As an OW2 user, I can download the binaries from OW2, but installating them can be a nightmare. AppHub a packaging of the binaries with the right choice of OS / version and the installation scripts, so that when the machine boots, everything installs itself, and the end user does not have to pull dependencies, install packages, ... Sometimes you don't want to run in Docker (on top of a Docker server) but directly inside a VM on top of the OS. With the Factory you package your project inside a "template" once, and generate any format. During AppHub, ALE tried on some OW2 projects, and in some cases the OW2 project does provide a doc, but it's really complex, so in this case the template is a good idea.
  • BMO asks whether AppHub is really used.
  • ALE mentions it's currently used by the CHOReVOLUTION European project. ALE will look at the stats. The real question for ALE is: does AppHub fulfill a need for OW2 projects to "deliver" their project software?
  • SLA and ALE decide they will submit a questionnaire to the project leaders to understand their needs in terms of software delivery and their interest in UForge.
  • SLA asks BMO whether they have or foresee the need to generate an image of FusionDirectory in qcow2 format, or AWS, or VMware etc. BMO's answer is "not for now".
  • For ALE, FusionDirectory is a good example: the environment that will be used in production is unknown, hence need of a template so that any image can be generated.
  • MHA reminds UForge being not open source could be a hindrance.
  • BMO asks whether the AppHub Factory can be integrated with GitLab.
  • ALE answers that integration with CI is the use case of some of their customers. They have a repo of binaires / rpm / whatever, and nightly they build a UForge template using hammr (OW2 project) to generate and publish the image. As for the provisioning, it can be done with the IaaS API [9]. UShareSoft has started the "deploy" (provision) features. The deploy part requires Apache Brooklyn to be installed which is not present on the AppHub infrastructure.

[8] https://mail.ow2.org/wws/arc/technology-council/2017-10/msg00006.html
[9] http://docs.usharesoft.com/projects/appcenter-user-guide/en/latest/pages/changelog.html

Voting system

  • OW2 has evaluated CIVS [10], which can be used as SaaS or on premise.
  • BMO mentions devotee [11] which uses a variation of the Condorcet method.
  • SLA proposes the use of CIVS online for the next board election. No objection raised.

[10] http://civs.cs.cornell.edu/
[11] https://www.debian.org/vote/

Next meeting

Fri. 1 December 11 am CET