On Sat, Aug 12, 2017 at 06:50:25AM +1200, Daniel Reurich wrote:

[cut]

>
> What I'm not comfortable with is the shit that you and parazyd have
> expressed about nextimes stirling efforts to stand up and host a
> platform that has allowed Devuan to come to fruition, but now you guys
> continue to insult him and his approach which in my opinion is actually
> really optimal, even if the minimal bits of glue he's written aren't
> examples of perfect programming. Nextime built the ci system single
> handledly and you continue to shit all over his work. I'm not concerned
> about Nextime reacting badly, but you guys continuing to insult his
> efforts to stand up a build system in short order.

Where I have ever insulted anyone? Please point to the relevant
emails/discussions. I am grateful with you and jaromil and nextime,
and I have never insulted any of you. Being grateful does not mean
that I have to agree completely with everything, and does not imply
that we must use the current infrastructure for ever.

Nextime himself wrote at the beginning of releasebot.py

########
# NOTE:
# this code has been written during a vacancy period in Tenerife,
# on the beach, in the pauses between some swimming and a little bit of sun.
#
# So, it's relaxed code.
#
#######

It's great that it has worked so far. Shall we continue to use that
"relaxed code" in saecula seculorum just because nextime wrote it
during a vacation in Tenerife?

[cut]

>
> I've worked hard to bring people like yourself on board to deal with the
> biggest risk factor I see with Devuan, and that is the absence of people
> like me and nextime preventing other people from working. I brought you
> in to help with getting people working with the build system we have -
> not to upend it with fanciful ideas of boutique alternative solutions.

So your "trust" to me was limited to me staying silent and obeying to
your orders? :\

You know, trust is not something that you dispense and other people
receive. Trust is a mutual thing.

> You repay that trust I extended and repay us by insulting nextime and me
> thinking you know better and have better solutions whilst in the same
> breath continue to ask me to explain how things work. It's not like you
> didn't have the source code for releasebot to study... but no that's too
> hard for you, ask Dan instead because he did work with it and study it,
> and took the time to understand how it functions.

The RFC parazyd and me have produced comes exactly from studying
releasebot. You still have not been able to nail down what I have not
understood of the current build infrastructure.

[cut]

>
> And when I started to pick the RFC to bits because it's most glaring
> problem was that it did not describe the particular problem is that it
> doesn't describe the problem (and you refuse to provide a clear
> statement on that), and I challenged the fundamental assumptions, you
> get all shitty saying we haven't provided a single solution. Well I'm
> not the programmer, but I have laid out clearly how the solution would
> look and what's minimally required to resolve each issue.

Please provide a list of reasons why the RFC is wrong, or
incomplete. You have not been able to do that so far, IMHO, or I am so
stupid that I was not able to discern these technical critics among
the insults.

[cut]

> > 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 :(
>
> I compare it with systemd because it exposes a style of engineering that
> is similar to Lennart Poetterings style. Not Invented Here syndrome
> comes to mind. It's an apt comparison as your proposing to replace a
> very minimalist tool missing some little features with a suite that
> includes it's own authentication and permissions system which and
> centralises control of the entire CI on itself. It's simmly the wrong
> approach at the wrong layer and absolutely reject any claim that it is
> single purpose, minimalist and focused.

You clearly have not understood what scorsh is for. It will still use
releasebot. It will only manage authentication of actions. You keep
saying that scorsh's approach is wrong, but you cannot nail down why
with technical arguments.

The current minimalist systems is so minimalist that does not allow to
do most of the things we need to.

> >
> > 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.
>
> Really... Scorsh provides:
>
> 1) an authentication system,
> 2) a permissions model of it's own
> 3) a tool that embeds json encoded commands in the git commits of the
> project using it.
> 4) a daemon waiting for a signal from a post commit hook from the git
> repsitory
> 5) a database of project specific configuration (replicating what can
> already be derived from gitlab and is stored in jenkins).
> 6) a unique command protocol all of it's own not based any common
> approach I've seen before.

scorsh provides only an authentication system to run remote
commands. The commands we will run are, guess what? releasebot.py...

2) there is no "permission model of it's own". scorsh provides a
mechanism. The policy is decided by whoever uses it.

3) this allows traceability of developer-triggered events. In the
current system we don't even know who messes up with a build.

4-6) these are part of the command processing system. If you want to
count them as separate, then it's your choice, but the total still
amounts to 500 LOC.

> >
> > 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.
> > a
> If you weren't so committed to scorsh why did you not dig into
> releasebot and implement my simple suggested solutions to your clained
> issues... most of them being figments of you imagination:

because releasebot cannot and should not do authentication, while
scorsh is meant to do that. Authentication is currently managed by
gitlab and the current setup does not allow to manage easily separate
permissions for different distros and different suites. What we should
do to make releasebot work with that is complicating it into a messy
harball of ifs.

>
> "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." (KatolaZ in email 25th August to devuan-dev)
>
> FACT: Anybody with greater then Master permissions on their own project
> if it is setup in jenkins, can build the project. This includes also
> masters in the group the project resides int
>

The fact you forget to mention is that once annybody is a master on a
project he/she can build the package for any suite. This means that
either we trust people *totally* or we don't trust them at all. This
is currently a blocker, and a major one, since we must trust project
"masters" to not shit on the production releases. And this requires
time. And this is slowing down Devuan terribly.

> "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." (same email as above)
>
> FACT: Only those with greater then Master permissions in the blessed
> gitlab group - configurable in the releasebot - can add, modify or
> delete a project from jenkins.
>

Yes, but if you are a master on that group, you can modify or delete
"any" job, belonging to any distribution.

The fact that you forget to mention here is that there is no
separation between releases and distributions. Shall we have a
"blessed" gitlab group for every suites/distribution? And shall we
check those permissions in releasebot by addind another long chain of
ifs?

[cut]

>
> My objection is that scorsh is a huge complex beast that has it's own
> authentication system that replicates project state data. It's not
> simple, it's not clean functional design and it's not based an proper
> evaluation of the issues.
>
> This is obvious as your continuing to lie about what releasebot can and
> cannot do and the separation of privileges it provides. You still don't
> understand the fundamental problems, so you can't possibly provide a
> valid solution!!

Can you please write a document about all this stuff, instead than
keeping saying that I don't understand anything? In particular, how
do you plan to implement privilege separation for suites and
distributions with gitlab and releasebot?

About the "lies": anybody able to read some python will immediately
understand that to allow releasebot to handle privilege separation for
suites and distributions we need to rewrite italmost completely
(unless your plan is, again, to add another handful of ifs around).

> > 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.
> > There is nothing mysterious at all about nextimes solution, because I
> have already multiple times exactly what is entailed. And we aren't
> going backwards, but we are wasting time discussing a non-solution to a
> largely imaginary problem.
>
> As I have said all along, define the problem and the solution will
> likely be obvious and simple.
>

The problem has been defined. We have talked about it at large during
the last developer meetings. Which you are still determined to ignore.

HND

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  ]