Changes to our Git infrastructure

[Jan Kundrát]

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?

>> 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.

>>> .NET is a framework, not a language. Maybe you meant C#. ...
>> 
>> Thanks for educating me, but I don't think it helps move this 
>> discussion forward in a productive manner.
>
> I do. Because there are a huge number of languages that have 
> compilers to produce .NET CLI. Some of them are indeed 
> relatively obscure. Saying .NET doesn't mean anything in terms 
> of which languages you are taking issue with. Let's be clear 
> what we're talking about.

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.

> As other people have added to the list of requirements, patch 
> management needs to be able to be done via the web UI. Nobody 
> has to install any runtime environment.

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".

The fact that I can fetch and upload patches via a website does not satisfy 
this requirement. It's a bandaid help, not a fully usable solution.

> 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.

> 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.

>> 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 :).

>> To put my money where my mouth is, yes, I am willing to 
>> maintain the extra systems, and I have been doing this with 
>> Gerrit (and CI) for a couple of months already.
>
> 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.

With kind regards,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/