Changes to our Git infrastructure

[Jeff Mitchell]

On 5 Jan 2015, at 4:27, Jan Kundrát wrote:

> On Sunday, 4 January 2015 19:32:28 CEST, Jeff Mitchell wrote:
>> I don't follow this line of logic. The end result is software stored 
>> in git trees, but how it gets there is a totally different concern. 
>> Whether it comes from patches that are then accepted and merged, or 
>> direct merging of branches, the end result is the same.
>
> - 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.

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.

>>> My goal is to help bridge the gap between the existing project 
>>> maintainers (who produce software in git trees) and the new 
>>> contributors (who produce patches).
>>
>> KDE purposefully has a very low barrier to entry. A contributor can 
>> normally push anywhere.
>
> When I said "a contributor", I was referring to somebody who is not a 
> KDE developer yet. Please re-read what I wrote again because your 
> understanding assumed that a contributor is someone who can push to 
> git. I can see why you arrived at what you said in that case, but 
> that's not what I said.

I misspoke. What I was thinking was that it is not difficult to get an 
Identity account and from there a developer account. Even so, an 
Identity account would be enough to get contributors acting.

> I was quite obviously referring to any tools which make use of the 
> .NET runtime environment. I do think that mandating these for 
> efficient work with our code review system is a pretty big no-go.

PHP and Java don't make use of it, so your statement was not obvious.

> The requirement I listed was "make the changes available as git refs 
> so that I do not use any other tool to work with them". If that is not 
> available, then another requirement is "have a nice CLI implemented in 
> a language that is common on KDE desktop".

I'm not saying that the first requirement isn't available. You're free 
to add any you like, but not expect that any particular request can 
necessarily be satisfied.

>> Those that want to contribute will be required to install a whole 
>> slew of development packages.
>
> Unless they have e.g. done something with Qt already, or unless 
> they're C++ developers already, etc.

In which case they're not going to be the type of people that finds 
installing another package to be onerous, if that is necessary.

>> Especially if it's only needed if they want to do advanced CLI stuff.
>
> Fetching patches is not advanced stuff. It's cool to have a manual 
> bypass for fetching stuff by hand, but that is a hotfix, not a 
> productive solution.

I would argue that a CLI tool in general would be considered advanced, 
and that most people are perfectly happy with a web-based code review 
paradigm. See e.g. GitHub, again. Regardless, nobody is arguing that a 
command line interface is a bad thing.

>>> The sysadmins appear to have a strong preference for a unified tool 
>>> to do both.
>>
>> No, our preference is for well-integrated tools, which is the same 
>> preference you previously stated.
>
> I'm happy to hear this, but then I don't know how to interpret Ben's 
> earlier responses in this thread and our conversations on IRC. Anyway, 
> it's cool that we agree on something :).

I don't know to which responses you are referring.

>> Yes, because Gerrit is not a tool being provided by the sysadmin team 
>> and as such is not in scope for us to maintain. It's great that 
>> you're willing to help out, but your offer to help maintain Gerrit 
>> has no bearing on whether or not it's what we end up proposing to the 
>> community.
>
> I'm simply stating that any possible argument saying "we prefer a 
> single tool because we don't have manpower to maintain more of them" 
> is moot because that manpower is waving its hand and saying "I'm gonna 
> do this" right now.

Consolidation would help decrease sysadmin burden. That's a general 
statement. The fact that you would be willing to administer Gerrit 
doesn't change the other systems that area already out there or that 
people might request.

--Jeff