Before commenting on specific things, let me say that I mostly agree with everything you wrote. On 24 January 2018 at 12:11, Martin Sivak <msivak@redhat.com> wrote:
Hi,
You`re asking a bigger question here - Who decides which distros/archs each project targets. The CI system currently places the burden of this decision on the shoulders of individual maintainers. We could have done things differently and placed the decision solely in the hands of the integration team.
Actually, I believe it should be a global decision of the project leadership. But I believe the word global to be important here. We should decide together and then a common version to platform map should be prepared by the integration team.
One thing here - I'm not sure who that leadership might actually be. As Red Hat employees we have managers that can make decisions, but I doubt we could refer to the as "The oVirt leadership". Red Hat managers can make decisions that are relevant to RHV, but not necessarily oVirt. Knowing some of those managers, most of them are not likely to make any cutting decisions. Furthermore, I do not think there is a community-based decision making process in place at this time. It seems that mostly decisions are taken based on what exists, and what could be done with reasonable effort.
Single projects could still add additional overrides if needed though.
The reason to placing the power (and responsibility) in the hands of maintainers we simple - we wanted to reduce the chances of having maintainers be surprised.
This actually means we get surprised and confused indeed. Please note that nobody really told us that Fedora bits are not going to be released anymore (see 4.2 release notes [1]) and whether we should update the job specifications or not.
WRT Fedora - I think the decisions to no longer release for Fedora was made because it stopped working and nobody stepped up to fix it. It was essentially made to ensure that the release documentation matched what existed in the code. WRT job specification - that one is on me, I guess that as the CI system maintainers we should communicate our expectations of maintainers better. The general rule is that we prefer to be concerned with _how_ the CI system does what it does and let maintainers decide the _what_. The is a grey area in the middle though, where we cooperate (For e.g we do some maintenance of OST test suits).
Suppose we made it so that target distros change globally for everyone - you would have had patches failing CI at arbitrary times as new target distros or architectures were added...
Right. But we have something very similar now: spreadsheets with lists of packages that are missing from a new version compose. I do not see too much difference actually..
Personally I prefer that decisions remain distributed
I agree with who decides things (all of us). But the decision needs to be documented. Do we have any (easy to find) list of expected platforms for given a release?
Nope. No central or consensus-based decision making process is in place ATM AFAIK, so no central file either. -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted