CI system maintainability

[Friedrich W. H. Kossebau]

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.

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?

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?

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