Re: Do we still want develop branch?

From: Robert Ramey (ramey_at_[hidden])
Date: 2023-11-06 16:37:55

On 11/6/23 1:24 AM, John Maddock via Boost wrote:
> 
>> The CI for the boost serialization does not and never has worked. This 
>> is easy to veryify just by looking at any of the CI output for this 
>> library.  And this demonstrable fact has been pointed out numerous 
>> times. This situation is never addressed.
>>
>> I doubt that the serialization library is the only one with this issue.
>>
>> The sadist part of all this is that even if it did "work" it would 
>> still be useless.  It's not uncommon for a large and/or complex 
>> library to fail one or more tests on one or more compilers due to 
>> issues in the compiler itself.  These can't be "fixed" in the 
>> library.  The test matrix shows all the tests x all the environments. 
>> One can easily see if any failure is general or isolated to a 
>> particular environment.  The current CI just registers pass/fail for 
>> the whole library and all the environments.  Some times someone will 
>> suggest skipping a particular test for a particular library so the CI 
>> comes of clean.  This is basically hiding the error.  Users 
>> considering using a library in their own enviroment are basically 
>> mislead that their the library works everywhere - which is 
>> demonstrably untrue.  It's a fraud.
> 
> Personally I find that CI works just fine, with one caveat: you do need 
> to update the scripts on a semi-regular basis otherwise you will find 
> lots of useless failures often caused by changes to the host environment 
> outside our control.  This of course reflects real world usage.
> 
> A typical example - clang on ubuntu jammy just stopped working - the 
> cause was an update of the system default compiler from gcc-12 to gcc-13 
> which rendered the clang version we were testing non-functional.  The 
> solution is to do what you would tell a user to do - update the clang 
> version to one that can handle gcc-13's std lib!
> 
>>

>> The output of the CI is very user unfriendly.
> 
> It's not awful, it's just a dump of the build output

Right - that's awful

  - just like you get
> if you run tests locally.  It could of course be better.

I had to write my own library_status program to make sense of it.  I've 
displayed the results on several ocasions to a universally unimpressed 
audience.  Oh well.  Of course this doesn't help when displaying CI output.

> I just do what I would do for console output and search for "..failed" 
> to find the failures.

I sometimes do that.  It's complicated by the inclusion of tests which 
are meant to fail compile and/or link. And a lot of noise.  Its not 
particularly useful when there is a failure in one environment and not 
in others - e.g. static vs linked libraries, etc.  The test matrix is 
much, much better for this.  Maybe the CI output could be funneled to a 
program which produces text matrix like output.  (oh wait, I'm already 
doing this!).
> 
> Oh and you can download the logs and process them yourself if you want to.
> 

Not all the information required is in the logs.  Some of it is in the 
process jam log program (or ?)  Now I don't remember.
>>
>> The current CI is very slow and consumes a ridiculous amount of 
>> resources.
> 
> Actually I'm astonished how fast it runs, 

actually I only concluded that from the fact that I often receive the CI 
output hours? / days? after a PR has been submitted.

It also runs the whole CI on the most trivial of changes - like removing 
a space from a comment.  Users often submit changes like this.

if you haven't updated your
> scripts in a while though, it's likely you're using github images which 
> have been deprecated, and will basically never run now (or take a very 
> long time to do so).
> 
> Resources, I would agree on.
> 
> Best, John.
> 
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost