Changes to our Git infrastructure

Jeff Mitchell mitchell at
Mon Jan 5 17:01:12 GMT 2015

On 5 Jan 2015, at 11:06, Jan Kundrát wrote:

> On Monday, 5 January 2015 16:05:07 CEST, Jeff Mitchell wrote:
>>> - Existing KDE account holders can and do use git for their 
>>> workflow.
>>> - Using non-git workflow for others introduces a different workflow 
>>> to the mix.
>>> - Having two workflows is more complex than having just a single 
>>> one.
>>> Does it make it more understandable?
>> No. What you're saying is "having two tools" is more complex. It's 
>> still one workflow.
> I feel like you're just language-lawyering here. The workflow I 
> propose pushes the burden of producing clean patches to the 
> contributor. The workflow you're advocating for appears to center 
> around sending patches around

"Sending patches around"? That's quite the stretch from "submitting a 
diff to a web interface" and recalls the KDE 1.0 days. And you're 
accusing me of language-lawyering?

The problem here is that you believe -- incorrectly -- that a single 
workflow cannot include more than one tool. The reason I can 
definitively say that you are incorrect is because your own preferred 
workflow involves more than one tool, regardless of how they interact. 
And if yours does, you can't complain about other workflows that do.

>> GitHub is a notable example showing that people don't seem to have an 
>> issue with a workflow that uses Git + a web-based tool to manage 
>> their code reviews. I'm not saying we need to end up with that, I 
>> just don't think it's credible to claim that it's too difficult or 
>> complex.
> That isn't an example that proves your point, though.

It does if my point was (and it was) that a workflow consisting of 
producing a commit in Git and having the review take place via a web UI 
is a very broadly accepted paradigm in software development, and one 
that is often considered to be friendly to newcomers.

> and I believe you were saying that it's fine for a CR tool to work on 
> patches and not git trees.

Correct. Although I recognize the merits of such an approach, I do not 
believe that the only acceptable way for a code review tool to work is 
on git trees instead of via patches. And I do not believe that this one 
feature is enough to outright dismiss all other options.

Given your earlier statements I imagine, but this is only supposition, 
that one of the reasons you desire such an approach is so that you can 
have all review actions be performed via SSH commands without requiring 
either a web UI or external tool. While this is certainly nice to have, 
I don't believe that it is very usable for newcomers (we've weathered 
enough complaints over the years about Gitolite SSH commands). Given the 
earlier distinction you made between contributors and developers, it 
also requires those that want to contribute patches to have full KDE 
developer accounts with commit/push access in order to push those diffs 
up for code review...something not required from a web interface 
requiring only an Identity account.


More information about the kde-core-devel mailing list