Changes to our Git infrastructure

[Jan Kundrát]

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.

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). 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,
- there's one less thing for a maintainer to do on a contributor's behalf,
- maintainers have more time to process more incoming reviews,
- contributors can eventually transition to maintainers more easily because 
they already know the tools.

>> - 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.
 
> 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.
 
> 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 because we 
still haven't achieved dominance even on Linux, and absolutely not on other 
OSes. 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. 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.

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.

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

My impression is that the goals for a code review tool are very different 
from needs for a project management tool. The sysadmins appear to have a 
strong preference for a unified tool to do both. As a (non-KDE) sysadmin, I 
understand the general reasoning, 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. 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.

Cheers,
Jan

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