Another proposal for modernization of our infrastructure

[Ben Cooksley]

On Sat, Jan 31, 2015 at 10:53 PM, Jan Kundrát <jkt at kde.org> wrote:
> On Thursday, 29 January 2015 22:57:33 CEST, Ben Cooksley wrote:
>>
>> Given that upstream has had multiple attempts now at an improved
>> interface, I would question whether they would be willing to accept a
>> user interface which is suitable for our needs. It appears that they
>> are quite comfortable with an interface many find unintuitive or
>> difficult to use. If they weren't, considering the number of backers
>> it has - one would think someone would have sponsored such an
>> interface.
>
>
> I don't think this is an accurate and fair description of upstream. They
> fixed a UI usability glitch that Martin complained about in less than 12
> hours. That sounds like they are pretty welcoming to 3rd-party feedback,
> IMHO.

I respectfully disagree.
Fixing a usability glitch and accepting a radical redesign of your
interface are completely different.

We're not the first ones to complain about it's interface but they've
not done anything to remedy this despite a complete redesign (which
reduced the level of functionality interestingly).

>
>> As for the CI backend, please mention what is wrong with Jenkins - if
>> it would be integrated to check code review submissions.
>
>
> The reasons for considering another CI platform are described in my report
> in section 3.3.

I see the following in that section:

1) A note that Jenkins is a "glorified job launcher" as we don't use
any of it's advanced functionality (which I refuted - it is much more
than that).
2) Some notes that a proposed patch may be based against a week old
revision. This is making assumptions about how a Jenkins setup would
be made - as we're in control of what it does there is nothing to stop
us trying to apply the patch on top of the latest code in Git.

In terms of checking dependency buildability, once again - this is
possible but we don't do anything like this at the moment to preserve
resources.

As for it not having a declarative configuration, we're in the process
of refining the Groovy based Job DSL script Scarlett wrote. This will
shift the configuration of Jenkins jobs entirely into Git, and
depending on how things work out - jobs could be automatically setup
when new repositories come into existence or when branch metadata is
revised.

This is 100% declarative - and also integrated into our existing
tooling reducing repetition and storage of information, without the
need to convert or replicate the information even temporarily. We may
even be able to eliminate the prepare-environment.py script, utilising
Jenkins functionality for this instead - and allowing us to eliminate
some of the commit hook complexity we have at the moment in the
process.

About the only point left standing is that it doesn't check individual
subcommits, but we've yet to see whether the KDE project as a whole
sees this as necessary - especially considering that the vast majority
of projects would use CI in an advisory role only for code reviews,
and would regular developers continuing to push directly
(necessitating post-push CI anyway).

>
> Cheers,
>
> Jan

Regards,
Ben

>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/