On Fri, Aug 11, 2017 at 11:16:36AM +1200, Daniel Reurich wrote:

[cut]

>
> Jaromil your not helping. Stop throwing your weight around and putting
> pressure on nextime. It won't solve things, just adds to his stress and
> given his recent situ I expect it's unwelcome and uncaring. Besides
> he's kindly built and hosted the CI infrastructure that devuan relies
> upon, and if you piss him off and he turns it off Devuan is dead in the
> water. So don't start sidelining him because he's got time difficulties
> at the moment.
>

This is indeed what really scares me, tbh. That one of us, a single
point of failure, can be pissed off at any time by a discussion on a
mailing list and decide to shoot Devuan dead, just because he/she
feels like it and can do it. Do you reckon what you are talking about?
And are you really comfortable with what you are envisaging? :(

I have been saying that having single points of faults is too risky
for Devuan. In theory, it should not be a problem among trusted adults
committed to a single shared cause. In practice, I am afraid that you
are talking quite childish here, and I don't think that the future of
Devuan can rely on the childish decisions of any single person.

But that's only my humble opinion. I have no power on deciding where
Devuan should go. The only thing I know is that Devuan cannot
fail. What you are talking about seems to go in another direction,
unfortunately :(

> We are not dealing with a broken CI system here, it still works fine for
> Devuan. Most of the issues scorsh is meant to deal with is wishlist
> items that IHMO can be better addressed by either patching existing
> tools or writing focused single purpose tools.
>

You keep saying that, but we have not seen a single solution. I posted
an RFC, and received no technical comments on it. Only hate, and
uninformed prejudices. scorsh is a focused single-purpose tool. It
does just one thing (command authentication). I don't know if it does
it well. But there is no wishlist item there.

> KatolaZ, I'm sorry, but I still fundamentally disagree with scorsh, and
> see it as a systemd like exploit being foisted on our CI system. It's
> bad engineering in this context.

Centurion, I have not yet understood why you disagree with scorsh, and
I would be more careful comparing scorsh with systemd, or to a
systemd-like "exploit", as a motivation. I simply expect more than
that from a technically skilled person like you :(

Scorsh is a single tool, that exactly does one thing, in 500 lines of
code, so I don't see any resemblance to the systemd-monster you are
talking about. Anyone who has looked into the code can understand
that.

I am not in love with scorsh. I don't get paid for it. I don't get
royalties out of it. We don't need to adopt scorsh at all costs. But
we agreed that we need to solve the current problems in the CI
infrastructure. scorsh provides a solution. You can ignore it, and go
for something else. I am totally fine with that. Only, I would
appreciate a technical motivation, if possible. If it's impossible to
have a technical motivation, I will live with that.

>
> I strongly object to scorsh having it's own authentication/permissions
> system built in. We already have a sufficient system for that in gitlab
> and which do not belong in a tool that should be a thin layer between
> gitlab and the ci system. And if we were to replace gitlab, we should
> move to a separate tool for providing federated authentication and
> permissions.
>

Scorsh is exactly that. A separate tool which does only and
exclusively authentication of actions. But again, I am not in love
with scorsh. I saw a series of problems in our current infrastructure,
mainly related to authentication and privilege separation. I saw
nothing git-based around and decided to write scorsh. I beg your
pardon for not having asked you the permission to do so, but you know,
programmers program for the joy of programming, expecially when they
code in their unpaid spare time :)

scorsh will still use releasebot, the current one, just refactored by
parazyd to eliminate a few of those long lists of ifs. The code is
available here:

https://github.com/parazyd/devuan-releasebot

Apparently, this scorsh-based solution is in line with what you are
now envisaging as a long-term plan. We don't have to adopt scorsh, and
noone is forcing anything. nextime agreed to provide an alternative
based on releasebot (btw, I hope that the alternative will *separate*
the authentication from the logic of releasebot, otherwise releasebot
will probably become a hairball).

> With regards to the website stuff, lets either fix the gitlab ci job or
> abandon it and go to the static html site.
>
>

OK. When will this happen? Who is in charge of it? Or more simply,
when will golinux be able to push those damn changes to the website?
Jaromil has become another single point of fault there, and this is
not sustainable. We simply can't wait for jaromil to have time to look
at it every few weeks or so. Devuan cannot remain stuck because any of
us is having a bad month at work :(

> Now if we are going to do anything to releasebot to fix it's glaring
> flaws fine. Lets define the issues and deal with them as should have
> been done properly before scorsh was ever started.
>
> I'll start:
>
> * has no test suite. (I've started writing one). This is top of the
> list as it reduces the chances of a patches breaking existing functionality
>
> * can't support multiple distro's - this can be resolved in 2 ways -
> either run a separate releasebot for each distro (requires a small
> patching to add the distro name to the job name) or adding support
> for distro handling.
>
> * architectures shouldn't be hard coded at job creation - they should be
> detected during source build
>
> * architecture should be a build time option (especially for initial
> build testing or rebuild of previously failed archs)
>
> * it doesn't have a listener daemon that can be used to trigger a build
> ( this would allow gitlab on commit webhooks to trigger builds or maybe
> a cutdown scorsh like tool). Could also be solved by a direct hook in
> jenkins.

I would add privilege separation to this list, which is a quite
important lack at the moment, since only gitlab project masters can
build a package, and once they can build it for a suite, they can
build it for any suite, potentially dropping shit in a production
release without any control at all.

No need to say that scorsh already provides support for those things
(and has a testsuite, which I am expanding further to cover the
specific needs of Devuan's CI) together with the slightly refactored
version of releasebot provided by parazyd. So I have already done
that. But you don't like scorsh, I got it (even if I don't get why, to
be honest. The only clear motivation so far is that scorsh was not
written by either you or nextime, who are the gurus of the building
infrastructure. Which is fine as a motivation, but again a childish
one.)

It seems to me that we are going backwards here. We had already
decided during the Devuan meeting on Wed 26th July that nextime was
having a go at refactoring releasebot to address the points above, and
we would have decided once we had seen his solution. nextime himself
said that the solution he had in mind (which is still pretty
misterious) would have convinced everybody. I am eager to be convinced
by nextime's solution.

HND

KatolaZ

P.S.: And just to reassure all of you, I will never run away and
destroy the little nothing I have contributed to Devuan so far in
doing so, however little and insignificant it is. I consider myself an
adult by now. And I consider Devuan much bigger and much more
important than any of my irrelevant idiosincracies, and of any bad
moment I can have in my life out of Devuan...

-- 
[ ~.,_  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  ]