CI system maintainability

[laurent Montel]

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
> 
> 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.
> 
> I was thinking of projects where there are multiple persons contributing/
> maintaining, like Frameworks.

For framework I use mainly phabricator
See https://phabricator.kde.org/people/revisions/196/


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

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