On Thursday, 29 January 2015 21:03:32 CEST, Eike Hein wrote:
I think it's a real concern, and I'm wary of "we can patch it away" because carrying a huge custom patch delta for UI mods is what kept us from upgrading Bugzilla for multiple years. I think "is it realistic that we can maintain this and keep up with upstream even if Ben or Jan get hit by a bus" is an important question with regard to both proposals.
That's a very good question, and a reason for why I am not patching Gerrit with stuff not accepted upstream. I agree that carrying big custom patches won't scale.
So far, we don't have any patches at all. I'll be backporting stuff such as the show-headers-prior-to-cpp from 2.11 because it is super-easy to do so, and because 2.11 isn't released yet.
We also have some JavaScript proof-of-concept for Bugzilla integration. You can check its complexity at [1]. I managed to write that over a Sunday, and I am definitely not a web guy. I had zero jQuery experience prior to this.
I have similar concerns with some of the promised benefits in the proposal because they strike me more of "we could", which is cool, but it's not "we will". E.g. if test build- ing precombined patches takes an OpenStack cluster - do we have one? Where are we going to get that horsepower? Can we keep it?
Designing contingency plans is indeed important (see section 5 of that proposal; it talks about managing infrastructure-as-code). You are also right that the current infrastructure is best-effort and that KDE won't get an SLA without paying for one. If we (KDE) need an SLA, we (the company the cluster is hosted at) will be happy to be asked for a quote :). Or we (KDE) can just host this stuff anywhere else and pay someone else.
But it seems to me that we already have pretty clear consensus that we absolutely do want a pre-approval CI coverage, and that the costs in HW are worth it. Does someone from KDE e.V. know whether we could get some free HW resources from a commercial partner (hi RedHat/SuSE/Digia)? Do we have some backup cash to e.g. rent VM time from Amazon/Rackspace/whatever in an unlikely event that the current hosting platform is withdrawn with no prior notice?
About the "we could" vs. "we will" in general, I have to admit I'm slightly confused by that. The proposal is careful to describe what is available today, and to make a clear difference in saying what needs to be done in future. Maybe some part needs clarification -- what parts do you think are more of the yes-this-would-be-nice-but-I'm-worried nature?
With kind regards, Jan [1] https://gerrit.vesnicky.cesnet.cz/r/static/bugzilla.js -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
