On 5 Jan 2015, at 4:27, Jan Kundrát wrote:
On Sunday, 4 January 2015 19:32:28 CEST, Jeff Mitchell wrote:
I don't follow this line of logic. The end result is software stored
in git trees, but how it gets there is a totally different concern.
Whether it comes from patches that are then accepted and merged, or
direct merging of branches, the end result is the same.
- Existing KDE account holders can and do use git for their workflow.
- Using non-git workflow for others introduces a different workflow to
the mix.
- Having two workflows is more complex than having just a single one.
Does it make it more understandable?
No. What you're saying is "having two tools" is more complex. It's still
one workflow.
GitHub is a notable example showing that people don't seem to have an
issue with a workflow that uses Git + a web-based tool to manage their
code reviews. I'm not saying we need to end up with that, I just don't
think it's credible to claim that it's too difficult or complex.
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).
KDE purposefully has a very low barrier to entry. A contributor can
normally push anywhere.
When I said "a contributor", I was referring to somebody who is not a
KDE developer yet. Please re-read what I wrote again because your
understanding assumed that a contributor is someone who can push to
git. I can see why you arrived at what you said in that case, but
that's not what I said.
I misspoke. What I was thinking was that it is not difficult to get an
Identity account and from there a developer account. Even so, an
Identity account would be enough to get contributors acting.
I was quite obviously referring to any tools which make use of the
.NET runtime environment. I do think that mandating these for
efficient work with our code review system is a pretty big no-go.
PHP and Java don't make use of it, so your statement was not obvious.
The requirement I listed was "make the changes available as git refs
so that I do not use any other tool to work with them". If that is not
available, then another requirement is "have a nice CLI implemented in
a language that is common on KDE desktop".
I'm not saying that the first requirement isn't available. You're free
to add any you like, but not expect that any particular request can
necessarily be satisfied.
Those that want to contribute will be required to install a whole
slew of development packages.
Unless they have e.g. done something with Qt already, or unless
they're C++ developers already, etc.
In which case they're not going to be the type of people that finds
installing another package to be onerous, if that is necessary.
Especially if it's only needed if they want to do advanced CLI stuff.
Fetching patches is not advanced stuff. It's cool to have a manual
bypass for fetching stuff by hand, but that is a hotfix, not a
productive solution.
I would argue that a CLI tool in general would be considered advanced,
and that most people are perfectly happy with a web-based code review
paradigm. See e.g. GitHub, again. Regardless, nobody is arguing that a
command line interface is a bad thing.
The sysadmins appear to have a strong preference for a unified tool
to do both.
No, our preference is for well-integrated tools, which is the same
preference you previously stated.
I'm happy to hear this, but then I don't know how to interpret Ben's
earlier responses in this thread and our conversations on IRC. Anyway,
it's cool that we agree on something :).
I don't know to which responses you are referring.
Yes, because Gerrit is not a tool being provided by the sysadmin team
and as such is not in scope for us to maintain. It's great that
you're willing to help out, but your offer to help maintain Gerrit
has no bearing on whether or not it's what we end up proposing to the
community.
I'm simply stating that any possible argument saying "we prefer a
single tool because we don't have manpower to maintain more of them"
is moot because that manpower is waving its hand and saying "I'm gonna
do this" right now.
Consolidation would help decrease sysadmin burden. That's a general
statement. The fact that you would be willing to administer Gerrit
doesn't change the other systems that area already out there or that
people might request.
--Jeff
