Changes to our Git infrastructure

Jan Kundr√°t jkt at
Mon Jan 5 16:06:32 GMT 2015

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, so by definition in your workflow there's a big difference in the 
way 3rd party contributors work as opposed to what KDE developers do. My 
proposal aims at closing this gap.

> 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. The GitHub workflow 
actually involves a `git push` to be done by the contributor. That means 
that the GitHub workflow relies on contributors to curate git trees, and as 
such I like that workflow [1] because both core developers and contributors 
produce the same sort of artefacts. It's a different workflow from 
uploading patches via browser or via some client-side tool, though, and I 
believe you were saying that it's fine for a CR tool to work on patches and 
not git trees.

[1] GitHub manages to screwup things when one does a rebase, but that's an 
implementation detail for the purposes of this discussion. Yes, it does 
make the workflow hardly usable for me.


Trojit√°, a fast Qt IMAP e-mail client --

More information about the kde-core-devel mailing list