[ovirt-devel] [ACTION-REQUIRED] Making accurate CI for oVirt 4.2

[Barak Korren]

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 at 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