CI system maintainability
montel at kde.org
Thu Mar 28 15:56:33 GMT 2019
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.
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
More information about the kde-core-devel