Changes to our Git infrastructure

Frank Reininghaus frank78ac at
Mon Jan 5 19:57:47 GMT 2015


2015-01-05 19:03 GMT+01:00 Jeff Mitchell:
> On 5 Jan 2015, at 12:40, Boudewijn Rempt wrote:
>> All this back-and-forth about cli tools actually sounds weird to me. I
>> know that the beginners who start hacking on Krita would never use any of
>> them. Git on the command line is often already something they can be rightly
>> proud of when they master the beginnings. Heck, I myself haven't used
>> rbtools, even though the reviewboard site urges it strongly. Let the real
>> experts use cli tools, and they can handle a bit of obscurity.
>> So I don't think obscure cli tools matter even one whit -- what matters is
>> having the nicest possible web tools that make life for people as easy as
>> possible. Ideally, people shouldn't need a kde identity to submit something
>> (patch, bug report, idea, screenshot, plea for help), and reviewers should
>> be able to drop into a private conversation with only very little effort.
> Agreed. We've been looking for more friendly, better-integrated, and more
> usable tools for a long time. Not just for newcomers, but especially for
> newcomers.

yes, I fully agree. It certainly makes sense to improve our tools such
that they are more convenient for maintainers and others who
contribute very frequently, but taking the needs of newcomers into
account is also very important. Ultimately, a constant stream of
newcomers is the only thing that keeps a free software project alive
in the long term.

I have read a large number of bug reports during the past few years,
and I have very often seen first-time contributions which consisted of
a patch which was generated by redirecting the output of "git diff" to
a file and then attached to the bug report. In my experience, thanking
the new contributor for their efforts and asking them to upload their
patch file to via the web interface has a
success rate of close to 100%, and often, the contributors will then
continue to fix bugs and submit more patches. I'm a bit worried that
any new patch review system which requires more effort before one can
submit a patch for review might put some potential new contributors
off. And I'm not talking about the requirement to not introduce unit
test regressions or follow the coding style or fix white space issues
here - that certainly makes sense! - but the effort that is required
before one can even use the patch review system.

Having said that, I do acknowledge that tools which are best suited
for newcomers may not be the most efficient to use for frequent
contributors and maintainers (and I appreciate all efforts that try to
improve the situation for the latter). I just wanted to highlight that
"as little setup effort as possible" may be a desirable property of a
patch review system if attracting many newcomers is considered an
important goal.


More information about the kde-core-devel mailing list