On 25/07/17 19:47, Ivan J. wrote:
> 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.

We don't need a hefty design document! We need to know what the
problems are you're trying to solve??
>
>> 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.

Granted - but in the case of what I gather scorsh supposedly will do,
we're not talking about issues that would be resolved by massive
multithreading and have big concurrent process problems, nor has it big
data crunching requirements where speed will be an issue.

Amprolla is a different use case, but I doubt that even there the
benefits of golang would have stood up against the practical issues a
change would have created.

>
> 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.
>
That sounds awfully alot like the attitude that Poettering uses to
justify brute-forcing systemd on Linux. It's naive and egotistical and
doesn't have the community interest at heart. Instead it sounds rather
selfish in that python isn't your preferred language. Perhaps it's
simply not your choice to make when it comes to devuan infrastructure.


With regards to why python?

Because that's whats already being used, and it's both functional,
doesn't need compiling - making quick to patch and run to solve
problems. It's fit for purpose for what is essentially glue between
bits of infrastructure like gitlab and jenkins.

In regards to my role, sure it's not a programming one, and never was
but I've had to fix bugs in amprolla, devuan-releasebot,
debian-jenkins-glue a number of times. But I do understand the big
picture and when you come in saying your going to turn everything over
and rewrite it from scratch when you clearly don't see the bigger
picture and understand how all the parts fit together, but still think
you can do it better, then you have simply become another Poettering...

Do you think you will be around in 6 months, or 12 months, 24 months
time?? I expect you'll be busy on some other exciting project (and so
you should) and you can bet your bottom dollar I'll be one of the poor
suckers around still supporting and maintaining whatever infrastructure
we have in some fashion or other... because that's the type of guy I am,
I play the long game, not inflexible, but not swayed by the latest fad
either, and I play the conservative line, looking to stability and
reliability because that's what I need for the systems that I support
for my clients. Feature additions need to be well thought out and well
executed to bring positive results without creating disruptive changes.

As it is I still don't understand what problems scorsh is trying to
solve but?

It's time to put scorsh aside and lets talk about the actual problems,
and then we can talk about how to solve them collaboratively. And if
that means having a separate meeting then lets organise it.

Cheers,
    Dan.

>
> _______________________________________________ devuan-dev internal
> mailing list devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>


--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722