Changes to our Git infrastructure

Kevin Ottens ervin at
Wed Dec 24 09:48:56 GMT 2014


On Wednesday 24 December 2014 00:20:18 Ben Cooksley wrote:
> Before we go ahead and jump to a new platform though - we need to know
> what we want.
> Can everyone please suggest what they think are the things they'd like
> to see feature wise?

Review wise, I'd like to be able to review full patch queues. Right now we're 
not dealing well with patches built on top of some other patches which makes 
it either painful for the contributor working around that, or painful for the 
reviewer who end up reviewing several patches squashed together.

I'd like to be able to comment both on the code and the commit log (currently 
that's just the code).

I'd like a finer grained voting system. It's fine that we got everyone the 
ability to vote, but not all votes are born equal. There's no easy way for 
people to know if a ship it is from a maintainer or someone less confident 
about the code base.

I'd like to be able to apply a patch straight from the review interface. 
Otherwise there's always this akward situation for patches where you validate 
them and then the person disappear for a while, the patch being applied much 
later if applied at all.

Contribution wise, I'd like a simple command line client which allows me to 
take my local patch queue and put everything up as separate reviews. Also if 
the patches were already up for reviews it should be clever and update the 
existing reviews not create new ones.

Feels like writing a letter to Santa Claus. Good timing. ;-)

> Note that while Continuous Integration is something which could
> integrate with this infrastructure, it is something which is not being
> re-evaluated at this time. Any attempt to include it within this
> discussion is considered off topic and out of scope.

Fair enough.

That said if we're talking about selecting a tool it's not completely 
transparent either. Some tools are better suited at running the CI before a 
patch gets in, doesn't seem to be the case with our current stack.

My point here is: whatever the change, we ought to make sure it's not tying 
our hands in the CI department. Knowing the outcome of the CI is important to 
me when I review.

Kévin Ottens,

KDAB - proud supporter of KDE,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list