There has been some discussion in contributor group about improving maintenance for our OMLx Rolling branch.
As I recall this is partly how to move packages to Rolling without having to rely on the current copying cooker to rolling repos periodically. To be fair that has worked and is less resource intensive. However this results in Rolling branch sometimes going for long periods without much being updated.
Any suggesitons on any aspect of Rolling maintenance are welcome.
One thing we need to do is make rolling more easily available to users. Experience shows users don’t install 4.3 and then use om-repo-picker to switch to rolling.
It’s time to release rolling ISOs semi-regularly (and announce them much like we announce rock releases).
Maybe we even need a new (code) name for them so people can easily tell the difference between rock and rolling - maybe something like ROME (an acronym for Rolling OpenMandriva Experience).
That could give us “OpenMandriva Lx 5.0 released” and at the same time “OpenMandriva ROME 2022.10 released” (rolling releases should probably have time based versioning given they move all the time).
From my point of view.
Until now, Rolling worked on the principle that we cyclically make a copy cooker to rolling. Meanwhile, Rolling was practically dead, there was only few updates, making Rolling a rolling release in name only and practically useless for users looking to experience a trully rolling or bleeding edge.
We also tried to enable “cooker2rolling” auto build script several times - which, after building a package for Cooker, automatically built the package for Rolling.
This option, in my opinion, also did not work.
Why? Well, it was turned on a few times and then turned off again, because in Cooker large numbers of packages were built, e.g. QT or Plasma / K stack and cooker2rolling was turned off for the duration of this build, and later, even after copying the cooker to rolling, the script was not turned on again.
Another thing is that the functioning of dual package builds only burden our builders. In my opinion, it is not necessary because it only generates a higher load on machines, higher electricity bills and slows down the work at Cooker.
Also this action made it difficult for us to track packages in rolling and see which did not build correctly. For example, we built 20 packages in the cooker and only 16 was compiled fine in rolling. Which later could cause us to miss these packages and cause problems with rolling.
Therefore, what am I suggesting.
I largely agree, except there’s a bit of confusion about some terms – cooker2rolling is the script that wipes out rolling and copies everything from cooker to it. The autobuild script is something different.
We probably won’t get around using cooker2rolling (the one that copies everything) from time to time, e.g. after some major component was updated in cooker and has been found to be working ok.
The original idea behind the autobuild script was that there could be times when large parts of cooker and rolling would be incompatible (e.g. during the upcoming transition from Plasma 5 to Plasma 6, or while rolling is sticking with somelibrary.so.1 while cooker has moved on to somelibrary.so.2), so packages making use of somelibrary would be linked to .1 in rolling and .2 in cooker.
But realistically, we were probably overthinking that, at points like that it probably makes more sense to just keep everything relevant for somelibrary in cooker only and use cooker2rolling when the transition is complete.
I agree the autobuild script has caused more damage than good, and we should turn it off for good.