Feature matrix for future infrastructure

Thomas Lübking thomas.luebking at gmail.com
Mon Jan 26 17:11:34 GMT 2015

On Montag, 26. Januar 2015 01:38:54 CET, Kevin Kofler wrote:
> Thomas Lübking wrote:
>> If you had followed the discussion or at least looked at that feature
>> matrix Milian started and that you liked to high-handedly deem as rubbish,
>> you'd have noticed that webfrontends to upload patches (like suggested
>> https://tools.wmflabs.org/gerrit-patch-uploader/) are available to follow
>> a "download tarball, edit, diff files by hand and upload the patch" ...

> An alternative process that also works with web uploaders is "git diff" or
> "git format-patch" (which any decent GUI for git can do, so it can be done 
> without ever touching the git command line) and uploading the 
> result. I find this much nicer to work with than "magic refs".
> [...]
> So, with my distribution packager hat on, I think a web upload feature 
> should be a requirement. (I also agree with other posters that it would be 
> more friendly to newcomers, too.)

I doubt there's any disagreement on a nice webfrontend to upload patches 
being mandatory.

Eg. I can very well see that somebody concerned w/ i18n would like to 
lookup code via cgit (or similar - no flames here, please ;-), download a 
single file, fix a so far untranslated string, "diff -pru" it with the 
original and simply upload the patch w/o even compiling the entire software 
The CI would give him the warm feeling that he didn't forget a brace or 
semicolon - as well as the maintainer who would "Many thanks, I'm really 
too sloppy w/ that i18n stuff" sumbit the patch by clicking a button in the 
review interface.

The thing I wanted to clarify was, that this actually *is* possible w/ 

The current demo setup would only require to add one of the -existing- 
I assume that it was simply not done (for the demo setup) because 
committing to :refs/for is just much more efficient for regular 
contributors to a project (like rbtools, but minus the extra CLI to 
learn/remember) than clicking through RB or similar.


More information about the kde-core-devel mailing list