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.
- Stop running the cooker2rolling automatic build script.
- Introduce the rule that every package built for Cooker is copied from the cooker/ repo to the rolling/x/ testing/ repository - where it will be handled by Q/A Team.
- Some packages will be disabled from copying, as was the case with cooker2rolling. The backlist would also apply to packages that might break the current rolling (like Bero’s planned changes to the filesystem). This will keep Rolling in good condition.
- When Cooker receives key changes, such as planned changes to filesystem or similar, and is stable, we can copy the entire cooker to rolling (as we do so far).
- Additionally, I agree with the opinion of bero.
We can name Rolling differently and release ISOs to it cyclically with the date year-month-(or even day) e.g. 2022-03-31 or 2022.03. Which will also allow us to be in the news about Linux periodically, like Manjaro, Garuda, Arch or PCLinuxOS etc.
- Changes to Rolling should be applied ASAP (after fixing python stuff/mass build in Cooker) and before breaking of cooker.