Changes to our Git infrastructure

[Jeff Mitchell]

On 5 Jan 2015, at 12:15, Thomas Lübking wrote:

> On Montag, 5. Januar 2015 18:01:12 CEST, Jeff Mitchell wrote:
> It's not a matter of what is possible, but of preferences (while we 
> probably all prefer to not return to send patches on mailing lists ;-)
>
> Since they may obviously cover a large range, "scale" seems a major 
> requirement on workflow and tools. Pure CLI access on alinged syntax 
> for efficient pros is as relevant as an easy GUI access for starters.

Totally agree.

>> 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.
>
> I'd assume operating on git trees is certainly far more important for 
> CI than for reviewing patches.

Yes, that's correct. But then we need to remember that there is a social 
component that is not finalized (and discussed in another thread), which 
is branch policy. Without operating on git trees, a developer could 
still be working on a feature branch and have a review going for the 
commits in that feature branch, and the CI could operate on that branch.

The harder integration (and by no means should be assumed impossible, 
I'm just not sure how easy it would be at the moment since I haven't 
looked) for CI with respect to git trees vs. patches would be for 
one-off patches that aren't keyed to branches. But, if we're talking 
about contributors, not KDE developers with commit access, then they 
can't work with git trees anyways; if someone is already a KDE 
developer, they could work in a feature branch.

Or not. Generally I'm happy providing tools and letting the various 
projects decide on their own preferred method for handling branches and 
patches.

>> 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
>
> I don't think this is actually a requirement - the review repo (maybe 
> even branches) could easily have other/lower credential requirements 
> than the vanilla one.

There aren't such things as review repos right now, even on the current 
infrastructure (you could consider clones to be that, but creating 
clones and scratch requires full KDE developer accounts). Yes, you are 
right that highly flexible branch policy may allow something like this, 
but right now there is no such thing as commit access without having a 
full developer account. I think changing that -- assuming tool support 
for this -- would be a deeper policy discussion that is probably best 
had in a different thread.

--Jeff