On 28 January 2018 at 09:32, Yedidyah Bar David <[email protected]> wrote:
> On Fri, Jan 26, 2018 at 3:45 PM, Sandro Bonazzola <[email protected]> > wrote: > >> >> >> 2018-01-24 11:11 GMT+01:00 Martin Sivak <[email protected]>: >> >>> 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 >> > > I'd like to clarify my own understanding re what should be done with > jenkins jobs. > > 1. You can still, and are very welcome to, have and maintain fedora > builds/jobs for your projects. > > 2. Not officially publishing builds does not mean you can't build them, and > if you do, they are still published in the -snapshot repos, so users that > do > want them, can have them. > > 3. If building for fedora will make the job(s) for your projects fail > constantly, > either because you have bugs there, or because you rely on some > infrastructure > packages (otopi, ovirt-setup-lib, etc) to work on fedora (and with > python3), > then it probably does not make sense to build yet for fedora - this will > simply > add noise. > This will cause more then just noise - if a project fails to build on any platform it explicitly targets - builds from all plaforms are blocked and do not get released to the '*-snapshot' repo. If you tell CI you want to support platfrom X, it holds you to it... I'm a little frustrated that this OT discussion derailed the original discussion of getting proper testing for 4.2. > > 4. If OTOH your project is independent, and works just fine on fedora, you > are > more than welcome to build (and then publish in -snapshot). Doing this will > very likely make the eventual transition to "fedora is supported" much > smoother. > > 5. This is really a per-project decision, so unless we start having > cross-project > discussions about this, you should decide for yourself. Just keep in mind > that > eventually we'll have EL8, which is very likely to be more similar to > current > fedora than to current EL7, so better prepare... (saying this also mainly > to > myself!). > > Best regards, > > >> >> >> >> >>> >>> > 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 >>> [email protected] >>> 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> >> >> >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > > -- > Didi > > _______________________________________________ > Devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/devel > -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
