Git Scratch-Pads for every account (not only developers)

Torgny Nyblom kde at
Fri Dec 31 09:03:04 GMT 2010

On Thursday 30 December 2010 17.55.35 Milian Wolff wrote:
> Hey all,
> I want to bring this topic to discussion. As developer of KDevelop and Kate
> I'm forced to jump through hoops to get code by new contributors in.
> Right now the workflow is like this:
> - new contributor says he has a patch
> - asked to created account on
> - asked to put patch on reviewboard
> - gets reviewed
> - if it's a single commit patch, I ask him to use git format-patch and send
> me the commit so I can git am it
> - if it's a new feature or a big bugfix consisting of several commits the
> above is just a royal pita, hence I ask him to make his git branch public
> somewhere (gitorious, github, ...)
> What I'd like to see improved:
> - give every i.k.o account the ability to use his scratch pad without having
> the developer status.
> - make it possible to create a review board entry based on a branch in a
> scratch pad repo. Bonus points for automatic/easier update of the diff based
> on this branch. And I know that reviewboard does not support anything but
> single patches (yes, I don't like this as well but I can live with it), yet
> something like `git diff $branch..master` can be automated.
> And for the final merging of commits I could simply add their clone as a
> remote and merge it just like I used to do on gitorious.
> BTW: Opening up scratch pad repos is probably also good for new people
> working on completely new plugins or apps, since they can use our git
> infrastructure from the beginning without first having to use
> gitorious/github/... I know that most people will run into problems sooner
> or later and need me or someone else to take a look at their code, hence
> "just work in a local clone at the beginning" is not an option.

I'm affraid that opening scratch for everyone will make our git solution into 
a new github/gitorious.

But I'm all for everyone can create a clone of a already hosted project. This 
will fix the concerns above and still keep the focus on KDE.


More information about the kde-core-devel mailing list