<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 28 January 2018 at 09:32, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">On Fri, Jan 26, 2018 at 3:45 PM, Sandro Bonazzola <span dir="ltr"><<a href="mailto:sbonazzo@redhat.com" target="_blank">sbonazzo@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>2018-01-24 11:11 GMT+01:00 Martin Sivak <span dir="ltr"><<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span class="m_-6599204065840389871m_-7558734182477851695gmail-"><br>
> You`re asking a bigger question here - Who decides which distros/archs<br>
> each project targets. The CI system currently places the burden of<br>
> this decision on the shoulders of individual maintainers. We could<br>
> have done things differently and placed the decision solely in the<br>
> hands of the integration team.<br>
<br>
</span>Actually, I believe it should be a global decision of the project<br>
leadership. But I believe the word global to be important here. We<br>
should decide together and then a common version to platform map<br>
should be prepared by the integration team.<br>
<br>
Single projects could still add additional overrides if needed though.<br>
<span class="m_-6599204065840389871m_-7558734182477851695gmail-"><br>
> The reason to placing the power (and responsibility) in the hands of<br>
> maintainers we simple - we wanted to reduce the chances of having<br>
> maintainers be surprised.<br>
<br>
</span>This actually means we get surprised and confused indeed. Please note<br>
that nobody really told us that Fedora bits are not going to be<br>
released anymore (see 4.2 release notes [1]) and whether we should<br>
update the job specifications or not.<br></blockquote><div><br></div></span><div>Integration team reported to the developers community that Fedora support was broken starting with Fedora 26 back on August 2017[1].</div><div>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.</div><div>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).</div><div><br></div><div>[1] <a href="https://lists.ovirt.org/pipermail/devel/2017-August/030990.html" target="_blank">https://lists.ovirt.org/pi<wbr>permail/devel/2017-August/0309<wbr>90.html</a></div><div>[2] <a href="https://lists.ovirt.org/pipermail/users/2017-November/085006.html" target="_blank">https://lists.ovirt.org/pi<wbr>permail/users/2017-November/08<wbr>5006.html</a></div></div></div></div></blockquote><div><br></div></div></div><div>I'd like to clarify my own understanding re what should be done with jenkins jobs.<br><br></div><div>1. You can still, and are very welcome to, have and maintain fedora<br></div><div>builds/jobs for your projects.<br><br></div><div>2. Not officially publishing builds does not mean you can't build them, and<br></div><div>if you do, they are still published in the -snapshot repos, so users that do<br></div><div>want them, can have them.<br><br></div><div>3. If building for fedora will make the job(s) for your projects fail constantly,<br></div><div>either because you have bugs there, or because you rely on some infrastructure<br></div><div>packages (otopi, ovirt-setup-lib, etc) to work on fedora (and with python3),<br></div><div>then it probably does not make sense to build yet for fedora - this will simply<br></div><div>add noise.<br></div></div></div></div></blockquote><div><br><br></div><div>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...<br></div><div><br></div><div>I'm a little frustrated that this OT discussion derailed the original discussion of getting proper testing for 4.2.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>4. If OTOH your project is independent, and works just fine on fedora, you are<br></div><div>more than welcome to build (and then publish in -snapshot). Doing this will<br></div><div>very likely make the eventual transition to "fedora is supported" much smoother.<br><br></div><div>5. This is really a per-project decision, so unless we start having cross-project<br></div><div>discussions about this, you should decide for yourself. Just keep in mind that<br></div><div>eventually we'll have EL8, which is very likely to be more similar to current<br></div><div>fedora than to current EL7, so better prepare... (saying this also mainly to<br></div><div>myself!).<br><br></div><div>Best regards,<br></div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="m_-6599204065840389871m_-7558734182477851695gmail-"><br>
> Suppose we made it so that target distros<br>
> change globally for everyone - you would have had patches failing CI<br>
> at arbitrary times as new target distros or architectures were<br>
> added...<br>
<br>
</span>Right. But we have something very similar now: spreadsheets with lists<br>
of packages that are missing from a new version compose. I do not see<br>
too much difference actually..<br>
<span class="m_-6599204065840389871m_-7558734182477851695gmail-"><br>
> Personally I prefer that decisions remain distributed<br>
<br>
</span>I agree with who decides things (all of us). But the decision needs to<br>
be documented. Do we have any (easy to find) list of expected<br>
platforms for given a release?<br>
<br>
The decision then might be compiled into a file we could include and<br>
stay current without manual edits.<br>
<br>
[1] <a href="https://www.ovirt.org/release/4.2.0/#no-fedora-support" rel="noreferrer" target="_blank">https://www.ovirt.org/release/<wbr>4.2.0/#no-fedora-support</a><br>
<span class="m_-6599204065840389871m_-7558734182477851695gmail-HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="m_-6599204065840389871m_-7558734182477851695gmail-HOEnZb"><div class="m_-6599204065840389871m_-7558734182477851695gmail-h5">______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
</div></div></blockquote></span></div><br><br clear="all"><span><div><br></div>-- <br><div class="m_-6599204065840389871m_-7558734182477851695gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>SANDRO</span> <span>BONAZZOLA</span></p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D</span></p><p style="font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat <span>EMEA</span></a></p><table style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium" border="0"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"><img width="90" height="auto"></a></td><td style="font-size:10px"><div><a href="https://redhat.com/trusted" style="color:rgb(204,0,0);font-weight:bold" target="_blank">TRIED. TESTED. TRUSTED.</a></div></td></tr></tbody></table><br></div></div></div></div></div></div></div></div></div></div></div></div></div>
</span></div></div>
<br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br></blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br><div class="m_-6599204065840389871gmail_signature" data-smartmail="gmail_signature">Didi<br></div>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Barak Korren<br>RHV DevOps team , RHCE, RHCi<br>Red Hat EMEA<br><a href="http://redhat.com" target="_blank">redhat.com</a> | TRIED. TESTED. TRUSTED. | <a href="http://redhat.com/trusted" target="_blank">redhat.com/trusted</a></div>
</div></div>