On Sat, Jan 31, 2015 at 10:53 PM, Jan Kundrát <j...@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/
