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
