On Wed, Jul 26, 2017 at 12:14:31PM +1200, Daniel Reurich wrote:

[cut]

> > 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.
>

You see, the current build infrastructure *is* heavily relying on
gitlab, and on its group management system.

This is not flexible enough, since once a person can build his own
project he can build it for *any* suite, also those in
production. This means that either we trust a person to be capable to
not break thing even in production, or we don't trust them at all.

That's pretty dangerous, because it would be great for people to start
contributing stuff in "experimental" or "-proposed", without having
the right (and fear) of messing up with stable stuff in "jessie".

This is not possible at the moment. scorsh makes it easy to implement
and to manage.


> > 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.
>

See above. You are still relying heavily on gitlab's user/group system.

> >
> > 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.


OK. Can you write this patch, please? This has become a serious
blocker, e.g. for maemo.

> >
> > 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.


Please see above. You say we can replace gitlab with anything else,
but we are still relying heavily on the gitlab user and group system
for privilege separation, so one of the two claims must be inaccurate,
at the least. How would you implement privilege separation with
post-receive hooks?

Git post-receive hooks is exactly what scorsh uses. This makes scorsh
independent from whatever platform you decide to use for the web
interface to git.


> >
> > 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.
> >
> 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.
>
> The claim that releasebot was never meant to solve these problems is
> entirely beside the point and doesn't mean that it's neither possible or
> particularly difficult to do.
>

OK, are you or somebody else ready to work on it? With what timescale?
Could you please provide a document which describes how the system
would work, so that we can comment on it before you decide to go down
a patch-hell hole that other people need to maintain afterwards?

Thanks

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[     "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[       @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[     @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]