Changes to our Git infrastructure

[Jeff Mitchell]

On 3 Jan 2015, at 18:37, Jan Kundrát wrote:

> On Saturday, 3 January 2015 21:35:12 CEST, Jeff Mitchell wrote:
>> On 3 Jan 2015, at 14:00, Jan Kundrát wrote:
>>> - Working on git trees, not patches. This directly translates into 
>>> making the contributors familiar with our workflow, and therefore 
>>> getting them "immersed" into what we're doing and helping bridge the 
>>> gap between maintainers and contributors.
>>
>> I agree that this is missing from the list of things people brought 
>> up but I'd appreciate an explanation as to how this is "directly 
>> translates into our workflow". As far as I can tell our workflow is 
>> what we make it; if contributions from outside a core team are done 
>> through a patch-based review instead of a git tree-based review, then 
>> patch-based review is our workflow.
>
> Because what we together produce is software stored in git trees, not 
> series of patches.

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.

> 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. Unless you set access permissions otherwise, 
there's no reason that a contributor, after having a patch reviewed, 
can't be the one to push it into the main repo. The difference is a 
social one; until you've been given the say so, usually new contributors 
do the right thing and run their changes by the maintainers.

> If we can offload the management of git trees to the contributors, 
> then the following happens:
>
> - contributors learn to master the same tools as the maintainers,

This will happen regardless of which tools are chosen.

> - there's one less thing for a maintainer to do on a contributor's 
> behalf,

This is only something the maintainer needs to do if you restrict access 
in the first place, which is not our normal way.

> - maintainers have more time to process more incoming reviews,

Same as above.

> - contributors can eventually transition to maintainers more easily 
> because they already know the tools.

Same as above.

>>> - Not needing a CLI tool in an "obscure language" (PHP, Java, 
>>> .NET,...).
>>
>> .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.

>> Regardless, I fail to see how any of those are "obscure".
>
> I sincerely believe that pushing Yet Another Runtime Environment to 
> our contributors is something which reduces chances of them 
> contributing. Would I install e.g. PHP to contribute to Qt? I probably 
> would because Qt is an excellent and high profile software project. I 
> don't think I would do this just to e.g. send a patch to a random KDE 
> app that I use twice a year, though, and I also can't imagine people 
> doing this to contribute to Trojita.

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. Even if you wanted to stick to command-line only, 
it's too bad that you think that sending a patch to a part of KDE is not 
worth the same amount of effort as sending a patch to Qt, but I suppose 
we can't all consider KDE to be an "excellent and high profile software 
project".

>> They're three of the most popular and widespread languages in the 
>> world.
>
> The popularity has to be judged with our target audience in mind

Yes...

> because we still haven't achieved dominance even on Linux, and 
> absolutely not on other OSes.

Which has what to do with it?

> I think that most of our contributors don't come from the pool of PHP 
> programmers, Java programmers, or those who use the .NET framework or 
> the most popular desktop OSes.

Me neither. I still fail to see how that's relevant.

> These languages/frameworks/environments have historically been alien 
> to us, and we are talking about tools that need to be on each 
> contributor's machine in order to participate in the development.

I have used git-annex successfully despite not knowing how to program in 
Haskell.

> You are free to disagree with my impression that e.g. requiring to 
> install PHP or Mono on a dev machine provides an extra step for 
> contributors to pass, though.

Those that want to contribute will be required to install a whole slew 
of development packages. I absolutely disagree that adding one more to 
the list of packages they copy and paste from the wiki will be the straw 
that breaks the camel's back. Especially if it's only needed if they 
want to do advanced CLI stuff. I don't think most first-time 
contributors or the occasional patch-sender will do that; they'll use 
the web interface. Those that are getting more involved can follow 
simple instructions if they decide they want a CLI tool.

>> The subject line is unfortunately a bit narrow, but since code ties 
>> into everything, changes to our hosting necessarily affects all of 
>> our other systems. Changing our git infrastructure is a reasonable 
>> time to look at changing other things as well. There are a number of 
>> capabilities we'd like to provide and a number of systems we'd like 
>> to be able to consolidate.
>
> It isn't clear to me what exactly is being reconsidered at this point. 
> I was told that CI is specifically not in scope, and now I read that 
> wiki pages and issue tracking is being considered. I don't understand 
> where the line was drawn and why.

The sysadmin team is continually looking at ways that the level of 
service provided can be improved to the KDE community as a whole. Better 
issue tracking and better project management have been something we've 
wanted since well before the Git migration and Redmine/Chili. The latter 
simply did not end up being a usable alternative to the current systems.

As I said, the subject line is unfortunately narrow. It excludes code 
review, too...yet that's been a major discussion topic in this thread. 
If that's in scope, I don't see why other systems related to how we 
manage and produce and track code are out of scope either.

> My impression is that the goals for a code review tool are very 
> different from needs for a project management tool.

Yes.

> 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 personally happen to think that the 
Atlassian tools are best-of-breed and fit the non-unified but 
well-integrated profile very nicely, but of course are (sadly) off the 
table for KDE.

> As a (non-KDE) sysadmin, I understand the general reasoning

(Which is not what you think it is)...

> , but at the same time, as a developer I do not really care about 
> that, and am strongly against using an inferior tool just because it 
> was easier to install and takes less effort to maintain.

...so are we.

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

--Jeff