[cooker] Handling of Rolling

Hi,
rolling is looking good so far -- hasn't broken badly, and has quite a few nice updates we don't want to bother 4.0 users with.

But I'm a bit concerned about minor updates that get pushed into cooker not making it to rolling (even though rolling is where in the end releases will happen), probably because people [including myself, got to get into it] tend to forget about the small updates once they're there. The auto-updater also never pushes stuff to rolling.

I wonder if we should reverse the logic here a bit: Right now, we push stuff from cooker to rolling/testing manually.
It may be better to have a way to manually mark packages that are not ready yet (e.g. toolchain updates that need more extensive testing) and automatically build everything not marked that way in rolling after a couple of days.

Keeping cooker and rolling separate is probably necessary, because for some things they will diverge A LOT at some point (imagine the Qt 5 -> Qt 6 transition that will likely happen next year... Got to get cooker to Qt6/Plasma6 quickly while keeping rolling stable).

Any thoughts/opinions?

ttyl
bero

2 Likes

Ignoring the fact that I think that the scheme in general is going to
be hard to maintain, I think we need a button to queue a commit to be
built for rolling and cooker at the same time. That way, it's a lot
easier to get stuff pushed into rolling.

I wonder if we should reverse the logic here a bit: Right now, we push stuff from cooker to rolling/testing manually.
It may be better to have a way to manually mark packages that are not ready yet (e.g. toolchain updates that need more extensive testing) and automatically build everything not marked that way in rolling after a couple of days.

Agreed.

I'm certainly in general agreement on the points made.