On Tue, Jul 25, 2017 at 10:55:58AM +1200, Daniel Reurich wrote:

[cut]

>
> Ok... can you lay out the changes your proposing for devuan-releasebot?
>

Parazyd and I are preparing a document about that. The main change to
releasebot will be making it readable, since at the moment it is just
a single 300-lines long main function, which does everything...

All the code from releasebot will be reused.

[cut]

> It's look in the releasebot jenkins_tpl folder for the job templates.
>
> I think it's best to do a separate sources.xml for each repo type (dak
> reprepo, minidak etc) and then configure it either via labels, or
> perhaps setting flags in the issue title or description box.

This is exactly where we are with parazyd. The best way seems to have
a set of xml templates for each distribution. The rest of the
information needed to identify a build will come from the naming
scheme of repos and branches.

> >
> > I am sorry if my questions look trivial, but I couldn't find anywhere
> > a proper doc explaining what is the current jenkins-to-dak setup in
> > Devuan.
>
> If you don't ask questions then you're more likely to make wrong
> assumptions.
>
> I'm not against you developing a new and potentially helpful tool, but
> was a bit peeved about the way that it was portrayed as a replacement
> when you clearly didn't understand (and still don't it seems) the full
> picture of how things work. Even I don't fully understand it all, but I
> have studied it in depth over the 2 years I've interacted with it.
>

OK, can you please document it somewhere then? The fact that you have
studied it in depth and you understands it is grand. The fact that you
and nextim are the only two people who understand how the whole thing
works is not as grand, since this is again introducing a single point
of fault. And in fact, since only you and nextime understand what is
going on, we have remained stuck on this for several months.

I have now being studying with parazyd the whole infrastructure, and
we are putting together a document that explains how it seem to work
and what the proposed changes are. Everybody with specific knowledge
is welcome to contribute to that document.

> Perhaps chatting to nextime and me about what the actual goals for
> scorsh are might be useful.

We can have a chat about scorsh any time. Most of how it works will be
explained in the same document I referred to above, because I am
convinced that documenting stuff is the best way of understanding (and
explaining) them.

Again: scorsh will not replace releasebot. scorsh is just an
authentication system, based on gpg-signed git commits, which allows
to run predefined commands on the server. It can be used as a way to
authenticate build commands, with separate sets of permissions for
different sets of repos. This is something we don't have at the moment
with releasebot (the permissions are either all or nothing, and the
authentication is based on gitlab).

>
> To be honest, I'm also a bit miffed at the departure from using python
> which is used in all the other parts of the infrastructure that nextime
> has built. It sets up immediate barriers to entry for me (I haven't
> explored go yet) to understand and interact more deeply in the code you
> write.
>
> My feeling is that we should settle on python as the language of choice
> for all devuan infrastructure tooling we build unless there is a
> compelling reason for a departure. So why does scorsh need to be
> written in go instead of python? What compellling feature does scorsh
> need that python lacks?? This is not an attack, but a legit question
> highlighting that you or I may not be the ones maintaining this code in
> the future and adding random programming languages shouldn't be done
> without considering the maintenance burden.
>

I am not asking you to maintain scorsh, or to help developing it. I am
in charge of it and willing to develop and maintain it for the
future. And parazyd is an experienced go programmer who is going
through the code to audit it.

Python is easy to write but very bad to maintain, and does not have
support for concurrency, which will be needed soon as we are going to
support other distributions and have more packages to manage.

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  ]