On Donnerstag, 29. Januar 2015 21:03:32 CET, 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.
Afaiu Jan's proposal, the default gerrit webui is "just yet another
frontend on a REST API" (on a sidenote: looking at that CLI thing, I wonder
whether and how hard it would be to have this integrated into kdevelop) -
so I'm not *that* concerned here (assuming the API will remain rather
stable across version iterations)
Given the multiple concerns on the gerrit webfrontend (not only in this kcd
thread) I however also assume that it should be not too hard to get a
serious improvement upstream.
That includes "If we endup w/ a -hypothetical- decision between 'powerful,
but the webfrontend sucks' and 'pretty ui, but the backend seriously falls
short', i'd be happily willing to help on an improvement here".
(At least from my POV, it should be simpler to fix some GUI than to get a
well scaling replication and CI backend - by the order of some magnitudes
;-)
cluster - do we have one? Where are we going to get that horsepower? Can
we keep it?
That indeed is a severe issue.
Having CI on precombined patches is a *really* great feature and, walking
around in a candy shop, I'd immediately drop a whatsoever shiny glossy
button UI to get one (and regardless on the actual tool - I would seriously
want that with phabricator, gerrit, reviewboard, ...), but if the feature
is not affordable, it's not a feature at all :-(
@Ben, Since this is mostly a peak performance limitation:
are there any statistics on the arrival of review requests? (It doesn't
help if we've the power during the week, but on Sunday afternoon, when
everyone wants to submit patches, you'll have to wait until Tuesday for the
results) - we might require some EC2 here to get this?
Cheers,
Thomas
