Hello all,
I'm starting to understand the proposed changes, and i have to say that about scorsh thing and permissions i totally
agree with Daniel.

July 26, 2017 2:14 AM, "Daniel Reurich" <daniel@???> wrote:

> On 25/07/17 23:48, KatolaZ wrote:
>
>> On Tue, Jul 25, 2017 at 11:30:19PM +1200, Daniel Reurich wrote:
>>
>> [cut]
>>
>>> As it is I still don't understand what problems scorsh is trying to
>>> solve but?
>>
>> One of the problems that scorsh is trying to solve is that at the
>> moment only two people can issue build requests on gitlab, besides you
>> and nextime, and these two people are me and Lydia_K. This is simply
>> not sustainable, and the permission system of gitlab does not seem to
>> be flexible enough.
>
> It is flexible enough. You have the permission to allow people to build
> by either giving them at least master permissions on a project by
> project basis, or adding them as master on the devuan-packages group to
> grant them the ability to build any package in devuan-packages. This
> already works.


Exactly, when i wrote releasebot the first thing i care about was permissions, and using project and
group permissions on gitlab you can have granular per project or by group permissions.

>> The other problem scorsh is trying to solve is the fact that there is
>> no privilege separation between who can issue a build and who can
>> modify a Jenkins job.
>
> Actually their is privilege separation. People need to have at least
> "master" privileges in
> https://git.devuan.org/devuan/devuan-repository-masters to be able to
> add/modify/delete projects from jenkins. This is independent of the
> permissions required to issue build commands for the project whicn only
> requires master permissions on the project itself.

This has been implemented, as Daniel well said, by using some "special" groups in gitlab.


>> The other problem is that we are going to support other distributions,
>> and we need to have separate authentication spaces for each of them.
>
> That is easily enough added using the existing mechanisms. We'd
> obviously need to refactor releasebot to handle multiple project configs
> - but that's not hard to add.

This is fairly easy to add by using other special groups ( one for each distro ) and
using a different path for suites in gitlab repos for single packages.


>> The other problem is that releasebot depends *heavily* on gitlab, and
>> effectively prevents the usage of anything different from gitlab.

> It only uses gitlab issues api on that side of things. We can easily
> add support for other mechanisms including ssh commands, git post commit
> hooks etc. This is a relatively trivial feature to add when we are
> working on a migration to another git repository platform or if someone
> else decides to use a different platform. I think we should split this
> functionality out so the gitlab polling is independent from the main
> functionality.


As long as we have a repo that can support groups and users on single project it's just matter to add
a library supporting any other system but gitlab.

>> You keep saying that it is possible to patch releasebot to do this and
>> that, but it's not easy to see how these patch will be implemented,
>> and who will implement and maintain them. And, after all, they will
>> just be *patches* to something that was not meant to solve those
>> problems.

I will write that patch, and i will maintain it. Patches is the way to evolve programs,
and they ARE meant to solve those problems :)


> The logic of releasebot is pretty straightforward, but needs to be
> refactored to make it more readable, and make adding the needed features
> easier to do.

Agree on that, and i'm back to maintain it.