[cooker] New repositories and policies

with the 4.0 release coming close (and the introduction of the rolling repository with it), it's time to talk about how we're going to maintain this...

I've discussed with QA people and drafted some ideas on working with the repositories here:

Everyone please read and suggest changes on the ML and/or in the TC meeting.
It's important that we use rolling/testing instead of pushing directly to rolling/release unless we want QA people to think rolling is just a fancy way of telling users to use cooker :wink:

QA will make an effort of getting stuff out of /testing.


1 Like

First i think we should disable self PR accept on our github organization repositories.

So PR for rolling/stable will always must be reviewed.

Says the guy who gives a shit .. Funny

How about to extend this feature:

Publish only on success all build_lists for each arch (checking by commit hash)

by making it default with arch excludes ?

Like by default builds must succeed on all archs, and to allow some arch to be excluded ie. list %{armx}, riscv


Honestly, I think this is a bad idea. We're biting off way more than
we can chew, and we're better off just committing to making releases
more often than doing this. The kind of work this requires would
result in almost double or triple the amount of effort to ensure
things stayed working, and I just don't see us being able to do that.

I agree with you, that this incerases the work. On the other hand somehow we need to keep arch repositories synced.

Like now it is hard to say how big is discrepancy between x86_64 and aarch64 and others.

That does not mean this proposal is okay to implement. If anything,
this is further incentive to _not_ do that.