Another proposal for modernization of our infrastructure

Eike Hein hein at
Sat Jan 31 20:11:19 GMT 2015

On 01/31/2015 08:57 PM, Alexander Neundorf wrote:
> hmm, looking back at our switch to git, I don't consider our standards for
> documentation of the developer workflow as very high unfortunately. :-/

Considering I wrote the majority of I guess I'll have to 
take that to heart, then ...

My vision for how to do a "use gerrit" page well would be to
lead with the minimal recipe for how to clone a project and
upload a change for review. It should put visual focus on
those couple of commands, and make explanation of what they
do secondary. It should also encourage the use of kdesrc-
build as an even quicker alternative. Most of the content
on the Qt page should only be much further down and less in-
your-face, or even on a secondary page, and framed as con-
venience tweaks useful when contributing regularly.

Basically similar to how programming languages or web frame-
works will structure their website these days, leading with
"get you started" info and putting effort into making that
a fast path.

It'd be nice to even make this recipe box a bit dynamic -
click something to get a project selector, pick the KDE
project, and get the commands shown adapted for copying
with the right repo URL inserted.

I think it's doable in principle, but I think the best-
case scenario is still to make gerrit be not a hassle on
coders; I think both its UI and the way you interact with
it have fundamental problems when it comes to non-code

I don't think this is shifting of goal posts either be-
cause (a) ReviewBoard already has some screenshot functio-
nality and we actually have policy in place to require
showing screenshots for review requests that change UI
(i.e. this is something gerrit will actually regress us
on afaics) (b) the very reason we entertain shaking up
our infra is because we're unhappy with limitations in
our tools.

> Alex


More information about the kde-core-devel mailing list