Ok, this is getting way out of control and it's turning into huge energy
vacuum. I thought working on Ascii was our priority now?? Let's not
get so distracted by this and get peoples backs up.

My understanding is that the ci system was mostly where I and nextime
lead by virtue of the fact nextime built and hosts it and I'm the most
experienced with it and have a similar understanding of how it works to
nextime.

That doesn't preclude others being able to contribute enhancements or
make suggestions, but forcing a solution like scorsh on us isn't a wise
move. And in any case, talking to me and nextime about the issues,
before creating a solution such as scorsh might have avoided this standoff.

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.

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.

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.

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.

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


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.

...

regards,
    Daniel.

On 10/08/17 17:55, Jaromil wrote:
> On Wed, 09 Aug 2017, KatolaZ wrote:
>
>> We know you are having other issues with your hw, but we agreed a
>> deadline two weeks ago, and the deadline passed one week ago. Is
>> there a way we can help with that?
>
> there is a fundamental question lying behind this situation, wheter we
> should treat developers in Devuan differently, which I believe not.
> If we discount such a long delay on something we agree is a very
> important matter, then we have to apply such discounts to everything
> and fall into a vicious "when its ready" posture which also Debian has
> and which ultimately fits only amateur and student activities.
>
> I believe we should aim for Devuan to be better than that.
> Sorry for the painful remark, but I'm quite sure Nextime understands.
>
> Once can also argue that we keep up with the "when its ready" and
> discounting all sorts of delayed promises by past and future
> developers, but then many of us would be less interested in this. If
> we manage to create a professional environment for our activity then
> we'll save more time for everyone and also have a quicker turnover of
> leadership which is healthy IMHO
>
> Personally about this task I believe the deadline has expired and we
> are left only with one well formulated proposal, your DIP and the
> route to remove dependency from gitlab to a more minimal approach
> using just scorsh and git.
>
>> On a related note, golinux is still swearing (well, she is not able
>> to, but if she could she would definitely swear) about the updates to
>> www.devuan.org. The problem is that the automagic thing that should
>> put the thing online (a gitlab pipeline) does not work, and apparently
>> has never worked once in the last six months at least, for some
>> unknown reason.
>
> the reason is the gitlab migration from the old host at Alberto's
>
> after that, the script broke. also it was a clunky thing barely used.
>
>
>> My humble suggestion is that we can try to use scorsh for that, if
>> you like. I have already been using it for a similar task on my own
>> webpages. This might be a way to test it further on a more simple
>> task than the interface with jenkins, and will give us the
>> opportunity to understand whether it might be a viable solution (I
>> personally believe only in the code I have tried myself).
>
> I agree with that, we did already in previous meetings. Its a good way
> to battle-test scorsh on a less mission critical start.
>
> ciao
>
> _______________________________________________
> 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