<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <span dir="ltr">&lt;<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">&gt; What I think we should do is to add support that once an official tag is<br>
&gt; done an official build will be triggered and done.<br>
&gt; The question is can the official build flow be automated? IIRC it involves<br>
&gt; using tarball + signing or some other manual work which isn&#39;t<br>
&gt; similar to the way nigthly rpms are built.<br>
<br>
</span>Please let it live separately from the main project development<br>
repository and its tags.. The spec file is also something that might<br>
be oVirt specific (because Fedora, RHEL and CentOS have a different<br>
dependencies and packaging requirements..) and should be separated<br>
from the actual upstream tarball source release. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
But a flow similar to distgit would be nice, let me release a<br>
component any time I want (with the necessary branch based way to<br>
ensure compatibility) and take the latest from the right branch for a<br>
compose.<br></blockquote><div><br></div><div><div>That&#39;s not automation, its just you (human) building the official build in COPR</div><div>rather in jenkins no?</div><div><br></div><div>Which again leaves us with the problem of maintainer not aware he needs to builds/not synced/away.... </div><div><br></div><div>If we can reach a common ground for all projects on how to use a single (or at least a small group)</div><div>of automation scripts that will do a formal build, then similar to what we do with nightlies we can collected</div><div>them into a &#39;pre&#39; repo which is candidate for release.</div></div><div><br></div><div> </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The reason I asked about COPR is that I already use it like that, I<br>
have a special COPR project where I release optimizer bits for 3.5 [2]<br>
and 3.6 [1] in the distgit fashion. And I have a separate project for<br>
master tests and will have a separate project for 4.0 rpms.<br>
<br>
[1] <a href="https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-3.6/" rel="noreferrer" target="_blank">https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-3.6/</a><br>
[2] <a href="https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-3.5/" rel="noreferrer" target="_blank">https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-3.5/</a><br>
<span class=""><font color="#888888"><br>
<br>
Martin<br>
</font></span><div class=""><div class="h5"><br>
<br>
On Wed, Jun 22, 2016 at 11:38 AM, Eyal Edri &lt;<a href="mailto:eedri@redhat.com">eedri@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak &lt;<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; - you as packager / maintainer should add your build to the release<br>
&gt;&gt; &gt; configuration file[1] or send an email with the link to your builds to<br>
&gt;&gt; &gt; the<br>
&gt;&gt; &gt; person handling the release<br>
&gt;&gt;<br>
&gt;&gt; Is there a way to automate this? Like giving you the URL of the<br>
&gt;&gt; release repository in COPR and using whatever latest package you find<br>
&gt;&gt; there?<br>
&gt;&gt;<br>
&gt;<br>
&gt; What I think we should do is to add support that once an official tag is<br>
&gt; done an official build will be triggered and done.<br>
&gt; The question is can the official build flow be automated? IIRC it involves<br>
&gt; using tarball + signing or some other manual work which isn&#39;t<br>
&gt; similar to the way nigthly rpms are built.<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Martin<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Jun 22, 2016 at 9:44 AM, Sandro Bonazzola &lt;<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>&gt;<br>
&gt;&gt; wrote:<br>
&gt;&gt; &gt; Hi,<br>
&gt;&gt; &gt; since it seems not clear how to get your package included in a oVirt<br>
&gt;&gt; &gt; release, here&#39;s the procedure:<br>
&gt;&gt; &gt; - a new build planned is communicated to <a href="mailto:devel@ovirt.org">devel@ovirt.org</a> from release<br>
&gt;&gt; &gt; engineering team<br>
&gt;&gt; &gt; - you as package maintainer should prepare your package to be released<br>
&gt;&gt; &gt; with<br>
&gt;&gt; &gt; desired version (<a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a>, spec, whatever)<br>
&gt;&gt; &gt; - you as packager should build your package in jenkins / koji / copr /<br>
&gt;&gt; &gt; whatever you use to build<br>
&gt;&gt; &gt; - you as packager / maintainer should add your build to the release<br>
&gt;&gt; &gt; configuration file[1] or send an email with the link to your builds to<br>
&gt;&gt; &gt; the<br>
&gt;&gt; &gt; person handling the release<br>
&gt;&gt; &gt; - if you correctly add your package to conf files, you&#39;ll have your<br>
&gt;&gt; &gt; package<br>
&gt;&gt; &gt; released and release notes updated.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; [1] like in<br>
&gt;&gt; &gt; <a href="https://gerrit.ovirt.org/#/q/project:releng-tools+topic:releases" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/q/project:releng-tools+topic:releases</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks<br>
&gt;&gt; &gt; --<br>
&gt;&gt; &gt; Sandro Bonazzola<br>
&gt;&gt; &gt; Better technology. Faster innovation. Powered by community<br>
&gt;&gt; &gt; collaboration.<br>
&gt;&gt; &gt; See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; _______________________________________________<br>
&gt;&gt; &gt; Devel mailing list<br>
&gt;&gt; &gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt;&gt; &gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Devel mailing list<br>
&gt;&gt; <a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
&gt;&gt; <a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/devel</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Eyal Edri<br>
&gt; Associate Manager<br>
&gt; RHEV DevOps<br>
&gt; EMEA ENG Virtualization R&amp;D<br>
&gt; Red Hat Israel<br>
&gt;<br>
&gt; phone: <a href="tel:%2B972-9-7692018" value="+97297692018">+972-9-7692018</a><br>
&gt; irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHEV DevOps<br>EMEA ENG Virtualization R&amp;D<br>Red Hat Israel<br><br>phone: +972-9-7692018<br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div>
</div></div>