Build script to help bisecting by cherry-picking compiler fixes

[Pavel Sanda]

On Sun, Nov 17, 2024 at 12:12:48PM +0100, Scott Kostyshak wrote:
> > Can you describe
> > 1) how exactly it works in backgrounds?
> 
> Do you mean backporting? It checks if a certain commit is in the log, and if not it cherry-picks it. For example:
> 
>   if ! git merge-base --is-ancestor "b73ab025" HEAD; then
>     git cherry-pick --keep-redundant-commits -x -X theirs "b73ab025"
>   fi

I meant how you now know which commit to look for. You have some database?
Once you know the fix the rest is trivial...

> > 1) Would you welcome if we create new repo in git.lyx.org so you don't need to deal with gitlab
> >    and other have easy commit access as well?
> 
> I think I would prefer to either leave it on GitLab or put it directly in the LyX repository under "development". The files are really light:
> 
>   $ du -sh lyx-tester/
>   144K	lyx-tester/

Having this within development directory of branch/master seems perfectly reasonable to me. 
But I leave it for you to decide what's best.

> > 2) We don't have working jenkins for us anymore on the french site, but I could prepare for
> >    you virtual machine with ubuntu on OSUOSL for automatic running of the tests and set it
> >    up for automatic emailing to our list in case of errros if that seems useful for you.
> 
> Yes, this would be amazing! I would really like this.

Ok, I will prepare this.

> Which Ubuntu version would it be? 

Any recent LTS is possible. The easiest is probably 24.04 if you don't mind.

> The tests take a long time to run (several hours on one CPU). So running the
> tests often would be a considerable amount of cycles/power. Would we run the
> tests once per day? This is OK for OSUOSL? 

We can ask to be on the safe side. But would it be possible to report more
precisely our demands and goals?

1) Goals I can imagine:
 a) your testing machinery on current stable & perhaps on some rolling system with
    continuous updates of TL & GCC? (i.e. 2x tests run in a day)
 a) compilation on legacy system to conform our minimanl demands (qt5 & gcc)
    and on rolling system having most recent qt6 and gcc? The stable configuration
    is IMHO well covered by feedback of the current dev base.

2) Demands:
a) How long takes one test? (Instead of "many hours" which can drastically change
   with different cpu's can you estimate ratio to e.g. total compilation time?)
b) Can your test work in parallel manner for 4 or 8 cores?

I think if we could get with an hour or half an hour of compute for parallel regime
that's negligible enough and we might not even ask.

> I would personally argue this would be a good use of our funds, to donate in
> compensation for the cycles; but I'm not sure how other developers feel about
> this.

I am not sure we communicated it publicly, but yes, we sent donation to OSUOSL
just some weeks back as a thanks for their hosting.

Pavel