I had said 20 UTC, will turn that into 20 CEST.

Result of the pad:
https://pad.dyne.org/code/#/1/edit/nXiySd0FPHvG8pBgGgImxA/aJ87TdwIEWiIk96GZcFwypnb
For those with access, current status was commited to:
https://git.devuan.org/devuan-infrastructure/infrastructure_doc/tree/master/infrastructure_proposed_changes


Summary of the summary (by evilham)
===================================
(2017-08-12 18:15 UTC)

This was a rollercoaster, when I started, I was heading to a much
different place than where I think I got.

My analysis / general comments (feel free to differ, keeping the
discussion technical).


This is a short summary of the already short summary on the pad, do read
the pad. This is also on the pad. Do edit the pad (this included).

- The current situation where GitLab is the source of *authorisation* is
not really acceptable. There are quite a few reasons ranging from
security to it being impractical (details in the pad).
- The current situation where releasebot uses GitLab Issues to decide
how to interact with Jenkins is also not even a short-term solution any
more.

A couple things where the proposed options (should) concur:
- The naming convention for the Jenkins jobs:
"<distribution|group>_<packagename>-<source|binary|repo>"
- The naming convention for the branches
"$DISTRO/$release", e.g. "{maemo,devuan}/jessie"
"suites/$release" --> equivalent to "devuan/$release"
- Valid(*) PGP signed commits should result in automatic build
(creation, modification, triggering, etc.)
(*) Valid here means both valid and authorised
- Giving build permissions to a large number of packages in the
experimental branch should not be much of a hassle (example use case)
- Checking who has permissions to do what with which packages should be
very easy. Right now, this info is hidden behind tons of clicks on GL.

Since there is no code to judge, this is gathered from what was said
that would be done on Releasebot:
- There are no real proposed improvements to the current workflow, it
keeps GitLab as a source of *authorisation* for Devuan and is extremely
vague about the way other distributions provide *authorisation*. It
looks like the proposed solution is to make them sign up for GitLab,
create dedicated groups for each distribution and have them use the GL
Issue workflow. Far from optimal.
- Current code is python, but hard to understand python. Refactoring is
badly needed, integration tests, etc. Basically a rewrite. Again, in
theory this already started, more transparency is needed.

About Scorsh:
- It is go, but it is easy to understand go.
- Its intent is not replacing Releasebot.
- Releasebot *could* replace Scorsh in the future though.
- Is already written, and has a good design, should be easy to modify
for the issues that have already been identified (and those that may be
identified).

Whatver we do:
- We need a different *authorisation* source, relying on GL for this is
insane even short-term.
- If we consider different options, they may not look much different
than Scorsh.

Something that has crossed my mind and can be seen as a middle-ground,
which may or may not be worth considering:
* Special permissions repository (per distro) with PGP signed commits by
whitelisted keys.
    - /users/EMAIL.{perm,pub} <-- (permissions/info) + public key
    - /groups/DISTRO/GROUP.{perm,members} <-- (perms/info) + members
* Permissions to be strictly defined in consensus, but must be easy to
extend
* Scorsh-like commands in commit body

- This would have the benefit of:
- Being easily adopted by other distributions, using their own
infrastructure.
- Easy (and secure) for us to update devuan's and other distro's
permissions.
- Not at-all depending on GitLab.
- Giving permissions is scalable.

- Has the inconvenient that:
- It would have to be implemented and integrated with releasebot
- Is not too different from Scorsh in that there is an authorisation
source and *some code* reacting to commits

- On the other hand:
- Scorsh could be modified to work like this.
- Releasebot could be rewritten to work like this.

--
Evilham