Changes to our Git infrastructure
mitchell at kde.org
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
>>> - Using non-git workflow for others introduces a different workflow
>>> to the mix.
>>> - Having two workflows is more complex than having just a single
>>> 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
> 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