CI system maintainability

Kevin Ottens ervin at
Thu Mar 28 15:46:07 GMT 2019


On Thursday, 28 March 2019 16:11:12 CET Friedrich W. H. Kossebau wrote:
> Am Donnerstag, 28. März 2019, 14:33:59 CET schrieb laurent Montel:
> > For example I works all days on kde (pim or other) when I wake up, or at
> > noon after my lunch or the evening, I will not wait several days for a
> > review because nobody has time to do it.
> > 
> > (For example I make ~ 15 commits by days on pim/ruqola/framework, I don't
> > want to wait several days/weeks until someone wants to review my patchs)
> Something might be lost in translation here, do you think, because you work
> daily on code of KDE projects, and other people (so potential reviewers) do
> not, this is an argument to do instant pushes of unreviewed commits?
> While I understand one can get impatient if not getting instant review of
> changes one would like to depend on with further changes (I know this well
> :) ),

That particular point is in part a tooling problem though. Phab doesn't make 
this situation easy to handle. I have to do very naughty things to git and arc 
to deal with those. I'm guilty of often piling a dozen patches and rewriting 
extensively my history locally before the lots hits the first round of 
reviews. :-)

> still this seems a flawed argument at least for part-time-contributors based
> KDE projects, where the people one co-operates with only have time now and
> then, like once per week. It could be seen unfair & ignorant to them if one
> simply ignores their opinion, because one has more time reserved/ available.

This is one of the big flaws of self-proclaimed meritocratic communities. You 
can out-commit someone and end up being the big decision maker hard to 
convince. Doesn't happen by malice in most cases I think, but it's a clear 
slippery slope.

> Not sure where this is from, but often I have seen an unwritten policy
> applied where people for a patch uploaded for review after one week of no
> response add a ping and then wait another week, before finally pushing the
> change. To me this seems a fair and reasonable policy, only ignores people
> who are on vacation for some more weeks or otherwise inactive, but I have
> not seen that ever been a real issue.

Agreed. It makes sense.
> Given the actual purpose of this thread, I would be more curious how you
> have CI integrated in your workflow? And where things could be improved, to
> prevent the current state of unhappiness for people who care about CI some
> more? Given you said you work daily on KDE projects, it seems that the
> brokeness of those projects on the KDE CI has slipped your attention. So
> how does this happen, and how could this be prevented, other than people
> having to hunt you down on irc and tell you :)

Definitely interested in this as well. It's not the first time we have Ben 
having to escalate to some form of threat regarding the state of the CI in PIM 
components. Although it's clear from the kde-pim list that the CI is making a 
lot of noise there. Either we collectively became too good at ignoring those 
emails, or it's too verbose (after all it's one email per component per build 
type, it piles up quickly).

Kevin Ottens,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the kde-core-devel mailing list