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/
