On Tue, 25 Jul 2017, Daniel Reurich wrote:

> On 24/07/17 23:32, KatolaZ wrote:
> > On Fri, Jul 21, 2017 at 12:15:05AM +1200, Daniel Reurich wrote:
> >
> > [cut]
> >
> >>
> >>
> >> Lets instead take a look at how it currently works.
> >> - So to start off with, devuan-releasebot does 2 jobs. It sets the
> >> jobs, and it triggers the jobs. Setting up the jobs consists of
> >> providing a bunch of parameters and little snippets of script that are
> >> laid on templates that make up the jenkins jobs. The builds themselves
> >> various bits of script provided via jenkins-debian-glue that do the
> >> actual work of building sources and packages. The built packages to are
> >> deployed to the respective repo in the repo job that has a script that
> >> signs and uploads the files to dak and then tells dak to get to work.
> >>
> >
> > Hi Dan,
> >
> > we think we have understood how releasebot works now, and parazyd and
> > I are working to integrate it with scorsh to start testing it
>
> Ok... can you lay out the changes your proposing for devuan-releasebot?
>
> > What remains unclear to me is how jenkins-debian-glue needs to be
> > modified in order to support more than just one distribution. Looking
> > at the commits on git.devuan.org, the Devuan configuration for
> > jenkins-debian-glue is the stuff in the "devuan/" dir.
> >
> > Now, is it possible for the same jenkins installation to use different
> > jenkins-debian-glue configurations to put stuff into different repos?
> > If so, can this selection be made by using a parameter to the build
> > command?
>
> 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.
> >
> > 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.
>
> Perhaps chatting to nextime and me about what the actual goals for
> scorsh are might be useful.

KatolaZ and I will come up with a document probably later today, about
the entire pipeline of this thing.

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

Golang is a great language which is much faster than Python and is built
for concurrency (which is something very useful that Python does not
have). Being fast as C I even wanted to rewrite Amprolla in Golang, but
I was told not to by people.

As for maintaining it, I'm not seeing why you feel like you need to be
able to maintain all these tools and put a burden on yourself? Both
KatolaZ and I understand and work with Golang, Python, and C. This is
why we are here to help. You have your role which to me doesn't seem
like a programming one, and I don't see why you are trying to force
Python.

--
~ parazyd
GnuPG: 03337671FDE75BB6A85EC91FB876CB44FA1B0274
GnuPG: https://parazyd.cf/FA1B0274.asc