CI system maintainability

[laurent Montel]

Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit :
> Hi Laurent,
> 
> 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?

I maintain pim* from several years, I fix bugs, I improve apps, I fix all bugs 
that I put in my code, so for this one I consider that I can commit without 
review them (as other guys on other project that they maintain).
For framework I mainly use phabricator.

> 
> 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
> :) ), 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.

KPIM doesn't have a big active team...

> 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.

2 weeks for a commit, for me it's too long. 
I understand why people can be demotivated when they must wait long time until 
having an answer.
I know that I don't participate a lot on qtcreator dev as we need to wait long 
time to have some review...


> 
> Given the actual purpose of this thread, I would be more curious how you
> have CI integrated in your workflow?

CI: sometime I look at it, sometime not, sometime some guys informs me that 
it's broken (I remember that Luca told me some days ago that a package didn't 
compile, so I fixed it).
Sometime my code compiles on local so for me it's ok but it's just that I 
forgot to trash my builddir.

> 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 :)

I think that Luca idea to send an email directly to the people which breaks 
code when it breaks from several commit is a good idea.

If I received directly a message about kcontact 19.04 after 1 days I fixed it 
directly. Master build correctly and unfortunately I don't have 19.04 and 
master in parallel.

Regards 

> 
> Cheers
> Friedrich


-- 
Laurent Montel | laurent.montel at kdab.com | KDE/Qt Senior Software Engineer 
KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, 
 www.kdab.fr KDAB - The Qt, C++ and OpenGL Experts - Platform-independent 
software solutions