CI system maintainability

[Friedrich W. H. Kossebau]

Am Donnerstag, 28. März 2019, 23:06:17 CET schrieb laurent Montel:
> Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit :
> > 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 :
> > > > 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.

Do you remember a reason why it is no longer the case?

IMHO bringing the build report bot back to the chat channel could help with 
the issue this thread is about.

People tend to look more often into the chat channel then in their email 
folder, so this bot would improve the visibility of the state on 
build.kde.org, also be in a public place so people can directly chat about 
any reasons.

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

Increasing the package version ideally should not result in CI breakages. 
Ideally CI only fails if there is a real issue, otherwise people just get 
used to it failing and do not give the deserved attention.

What would prevent you to turn to a system like used with KDE Frameworks, 
where there is some internal dependency version and a separate actual 
version, with the actual version bumped earlier and the internal dependency 
version only bumped some days later? From what I saw, you increase versions 
quite often in PIM, so related breakages would happen quite often.

Cheers
Friedrich

PS: Okay if we start to slim the list of CC:s a bit now? Would leave out 
plasma, kdevelop, frameworks-devel on any next reply at least.