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

[Sandro Bonazzola]

2018-01-24 11:11 GMT+01:00 Martin Sivak <msivak at redhat.com>:

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

Integration team reported to the developers community that Fedora support
was broken starting with Fedora 26 back on August 2017[1].
We also reported during the beta process that oVirt 4.2 would have not
supported Fedora to user list  in November 2017 [2] since nobody fixed
Fedora support in the meanwhile.
No request or direction about what to do with Jenkins fedora jobs has been
issued since we (integration team at least) want Fedora support back in 4.3
but since we don't have yet a schedule for 4.3 we don't know yet which
fedora version we'll target. In integration team we are now slowly enabling
jobs on master for fc27 and fcraw (rawhide).

[1] https://lists.ovirt.org/pipermail/devel/2017-August/030990.html
[2] https://lists.ovirt.org/pipermail/users/2017-November/085006.html




>
> > 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?
>
> The decision then might be compiled into a file we could include and
> stay current without manual edits.
>
> [1] https://www.ovirt.org/release/4.2.0/#no-fedora-support
>
> Martin
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>



-- 

SANDRO BONAZZOLA

ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D

Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20180126/594e1bba/attachment-0001.html>