On Monday, 5 January 2015 18:01:12 CEST, Jeff Mitchell wrote:
The problem here is that you believe -- incorrectly -- that a
single workflow cannot include more than one tool. The reason I
can definitively say that you are incorrect is because your own
preferred workflow involves more than one tool, regardless of
how they interact. And if yours does, you can't complain about
other workflows that do.
I was complaining about an IMHO artificial split where drive-by people
submit changes in a different way than core developers. I stated that this
introduces some needless difference to the way devs and contributors work,
and that we should check whether there are tools that remove this
difference. I know that e.g. Gerrit removes that difference, so I am not
thrilled by the idea of using something without that feature.
It does if my point was (and it was) that a workflow consisting
of producing a commit in Git and having the review take place
via a web UI is a very broadly accepted paradigm in software
development, and one that is often considered to be friendly to
newcomers.
You're right, and I apologise for not understanding you correctly, we're in
violent agreement after all.
and I believe you were saying that it's fine for a CR tool to
work on patches and not git trees.
Correct. Although I recognize the merits of such an approach, I
do not believe that the only acceptable way for a code review
tool to work is on git trees instead of via patches. And I do
not believe that this one feature is enough to outright dismiss
all other options.
That's another thing where I should have probably worded my responses
better. The requirements I listed were things which I found valuable for my
work. I did not mean to say that it's the only possible way of doing
reviews, or that I found everybody who disagrees with me to be a moron.
It's just that these features are important for me, so I would like to see
them and I wanted to make sure they are listed as a requirement in a list
of points gathered by the community.
Maybe this misunderstanding is caused by sysadmins likely perceiving the
requrements as hard ones which MUST be provided by any solution, while my
impression is that we were asked to say what is important for us, and the
evaluation is to be performed by us all together, not just the sysadmins.
Given your earlier statements I imagine, but this is only
supposition, that one of the reasons you desire such an approach
is so that you can have all review actions be performed via SSH
commands without requiring either a web UI or external tool.
While this is certainly nice to have, I don't believe that it is
very usable for newcomers.
I agree that *that* would suck :).
Given the earlier
distinction you made between contributors and developers, it
also requires those that want to contribute patches to have full
KDE developer accounts with commit/push access in order to push
those diffs up for code review...something not required from a
web interface requiring only an Identity account.
There is no need for full KDE developer account to upload changes for
review with Gerrit. All that is needed is a regular Identity account.
Behind the scenes, it works by Gerrit being a special git server which
intercepts pushes and stores each of these changes in a separate ref. I'll
be happy to go into more detail in another thread, off-list or on IRC.
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
