Re: CI system maintainability
- Date: Thu, 28 Mar 2019 23:06:17 +0100
- From: laurent Montel <montel@xxxxxxx>
- Subject: Re: CI system maintainability
Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit :
> Thanks for reply. More below:
> Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb 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
> > > > 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
> > > 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.
> I was thinking of projects where there are multiple persons contributing/
> maintaining, like Frameworks.
For framework I use mainly phabricator
> So for projects where you are the only person who has any real insight,
> indeed I agree to pushing directly, as I do that as well :)
> Because IMHO the costs for having to hope & wait for somebody else to do a
> "review", where one then spends lots of time rather explaining things to
> someone, who is not really into the project and also never might be, is not
> anywhere worth the time one could have otherwise invested in fixing other
> existing bugs or adding new features or improving code quality.
> If people want to get into a project, doing own patches or just watching the
> commits and asking normally on irc or by email about the architecture
> should work good enough. Abusing reviews for teaching about some project
> would annoy me at least, usually the patch is to fix some annoying bug or
> add a wanted feature, so it should get in as early as possible.
> > > 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
> > > change. To me this seems a fair and reasonable policy, only ignores
> > > 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.
> Well, 2 weeks is the time-out, only reached in worst case. Ideally people
> give some feedback before, which often enough happens. And indeed one also
> has to hunt people down to get a review, like at meetings or in chat (or
> trade review work with each other :) ). But isn't this the same also at
> work- work, unless there is a dedicated review team which needs to react by
> itself? Co-operating on something needs social interaction after all.
> > > 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.
> So you do not go on yourself to build.kde.org and check yourself? Does #kde-
> pim have a bot reporting build failures?
Long time ago we had it in #kontact.
It's not the case now.
> For what I can tell e.g. for KDevelop, personally I rely on the bot on
> #kdevelop reporting the CI state/build results, as I only look at emails
> rather once a day, while the chat channel is more real-time, and one also
> can immediately talk to peers about why some build now fails, as well as
> coordinate who will fix that.
> > > And where things could be improved, to
> > > prevent the current state of unhappiness for people who care about CI
> > > 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.
> Noted. Personally I would also fancy that over the generic mass emailing,
> where most of the time it was somebody else breaking stuff, so they should
> care. Given the time-offset due to build times it is also unclear who broke
> things, given the email is not easy to parse, and one might already be off
> again to other things in life.
> Question is: when would you read the email, and how quick would you react?
I read it sometime as it arrives in my kdepim-devel mailbox, but indeed
sometime we can have several mail in same time because we increase a package
dependancy and it breaks all other packages. So indeed I didn"t look at all
But when a people signals me a problem I try to fix it quickly.
An email send after 1 day that package is broken can be a good idea, so it
can't be a dependancy problem because we increase package version just that
it's really broken.
> One could say, Ben has had to simulate such a email bot already a few times,
> and seems that worked to some degree (and I do not want to say we respect
> Ben as much as we would respect a bot sending such email, hm, how do I get
> out of this logic... ;) )
Laurent Montel | laurent.montel@xxxxxxxx | 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