Changes to our Git infrastructure

[Jeff Mitchell]

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.

> - Not needing a CLI tool in an "obscure language" (PHP, Java, 
> .NET,...).

.NET is a framework, not a language. Maybe you meant C#. Regardless, I 
fail to see how any of those are "obscure". They're three of the most 
popular and widespread languages in the world.

> I'm confused by this part. This thread is called "Changes to our Git 
> infrastructure". I see that "code review" is very relevant to that 
> because some efficient tools do extend Git, but I don't understand why 
> this list contains information about wikis, bug tracking and task 
> boards. I do not think that we should be looking for a single tool to 
> do everything (and the kitchen sink), so I would appreciate a bit more 
> information on what exactly your opinion is here, and why so.

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.

>> - A weaker case exists for clone repositories - making them more
>> nice to have than critical.
>
> I believe that people requested a place to store their changes which 
> for some reason cannot be easily upstreamed, but at the same time they 
> do not want to "bother" other folks by having a visible branch "in 
> your face" in the main repo. If that is indeed the case, we should 
> focus on this *concept* and put away the fact that it's right now 
> implemented as GitHub-style "repository clones". Other tools might 
> very well support such a scenario by something entirely different from 
> clone repos.

In this example it's the same as a scratch repo concept. The clones were 
meant for GH-style forks, as Gitolite eventually got the capability to 
do merge requests.

>> A single application which handles everything will always be able to
>> offer a better and more coherent experience than several applications
>> we have connected to each other.
>
> I do not agree with that. Well-integrated applications which work well 
> together while doing one thing well are superior to a single tool 
> which tries to do everything.

I don't think this broad generalization is any more valid than a broad 
generalization that single applications are always better. Regardless, 
we have never found a single application that handles everything 
acceptably, so I think this point is moot.

> I am volunteering to get my hands dirty, and I believe others have 
> expressed their willing to join the sysadmin team as well. In 
> particular, I'll be happy to take care of the Gerrit deployment

I believe you are on the hook for this regardless :-)

>> As this is quite an extensive list of requirements, we won't be able
>> to get everyone what they're after. We'll have to do things on a best
>> effort basis - depending on what is available, what features are
>> missing, etc. Unfortunately there is no perfect solution here - it
>> just does not exist.
>
> I can see all of the above fulfiled with Gerrit, but I'm OK with 
> waiting with a proper evaluation when we call for one.

I can see the above fulfilled with many tools. Gerrit is not 
automatically the choice simply because it checks many boxes.

--Jeff