On 5 Jan 2015, at 12:15, Thomas Lübking wrote:
On Montag, 5. Januar 2015 18:01:12 CEST, Jeff Mitchell wrote:
It's not a matter of what is possible, but of preferences (while we
probably all prefer to not return to send patches on mailing lists ;-)
Since they may obviously cover a large range, "scale" seems a major
requirement on workflow and tools. Pure CLI access on alinged syntax
for efficient pros is as relevant as an easy GUI access for starters.
Totally agree.
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.
I'd assume operating on git trees is certainly far more important for
CI than for reviewing patches.
Yes, that's correct. But then we need to remember that there is a social
component that is not finalized (and discussed in another thread), which
is branch policy. Without operating on git trees, a developer could
still be working on a feature branch and have a review going for the
commits in that feature branch, and the CI could operate on that branch.
The harder integration (and by no means should be assumed impossible,
I'm just not sure how easy it would be at the moment since I haven't
looked) for CI with respect to git trees vs. patches would be for
one-off patches that aren't keyed to branches. But, if we're talking
about contributors, not KDE developers with commit access, then they
can't work with git trees anyways; if someone is already a KDE
developer, they could work in a feature branch.
Or not. Generally I'm happy providing tools and letting the various
projects decide on their own preferred method for handling branches and
patches.
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
I don't think this is actually a requirement - the review repo (maybe
even branches) could easily have other/lower credential requirements
than the vanilla one.
There aren't such things as review repos right now, even on the current
infrastructure (you could consider clones to be that, but creating
clones and scratch requires full KDE developer accounts). Yes, you are
right that highly flexible branch policy may allow something like this,
but right now there is no such thing as commit access without having a
full developer account. I think changing that -- assuming tool support
for this -- would be a deeper policy discussion that is probably best
had in a different thread.
--Jeff
