Changes to our Git infrastructure
mitchell at kde.org
Sat Jan 3 20:35:12 GMT 2015
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 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
>> - 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.
More information about the kde-core-devel