<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 22, 2016 at 2:17 PM, Martin Sivak <span dir="ltr"><<a href="mailto:msivak@redhat.com" target="_blank">msivak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> That's not automation, its just you (human) building the official build in<br>
> COPR<br>
> rather in jenkins no?<br>
<br>
</span>It is automated enough for me, I just upload (the equivalent of<br>
tagging) the srpm and it builds it for all platforms. It is then<br>
automatically released in the project repository.<br></blockquote><div><br></div><div>Again, you're thinking on a small group of maintainers that might think as you,</div><div>less on oVirt as a sum of 60+ different projects. </div><div><br></div><div>While what you are suggesting might be an improvement of existing system,</div><div>I am thinking on a full automated solution for all projects that will be handled</div><div>in a similar way to nightlies and verification done on CI.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
COPR is not just a build system, it also exposes repositories for<br>
projects and you can easily use it from dnf.<br>
<br>
It is also much easier to use than what we have, because I can have a<br>
separate configuration for different releases and distributions. This<br>
is much harder when the release is directly tied to the upstream<br>
source repository. And I am using upstream in the project source sense<br>
here, oVirt is downstream in that sense (as is Fedora or RHEL).<br>
<span class="HOEnZb"><font color="#888888"><br>
Martin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Jun 22, 2016 at 12:59 PM, Eyal Edri <<a href="mailto:eedri@redhat.com">eedri@redhat.com</a>> wrote:<br>
><br>
><br>
> On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>> wrote:<br>
>><br>
>> > What I think we should do is to add support that once an official tag is<br>
>> > done an official build will be triggered and done.<br>
>> > The question is can the official build flow be automated? IIRC it<br>
>> > involves<br>
>> > using tarball + signing or some other manual work which isn't<br>
>> > similar to the way nigthly rpms are built.<br>
>><br>
>> 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>
>><br>
>> 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>
><br>
><br>
> That's not automation, its just you (human) building the official build in<br>
> COPR<br>
> rather in jenkins no?<br>
><br>
> Which again leaves us with the problem of maintainer not aware he needs to<br>
> builds/not synced/away....<br>
><br>
> If we can reach a common ground for all projects on how to use a single (or<br>
> at least a small group)<br>
> of automation scripts that will do a formal build, then similar to what we<br>
> do with nightlies we can collected<br>
> them into a 'pre' repo which is candidate for release.<br>
><br>
><br>
><br>
><br>
>><br>
>> 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]<br>
>> <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]<br>
>> <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>
>><br>
>><br>
>> Martin<br>
>><br>
>><br>
>> On Wed, Jun 22, 2016 at 11:38 AM, Eyal Edri <<a href="mailto:eedri@redhat.com">eedri@redhat.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <<a href="mailto:msivak@redhat.com">msivak@redhat.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> > - you as packager / maintainer should add your build to the release<br>
>> >> > configuration file[1] or send an email with the link to your builds<br>
>> >> > to<br>
>> >> > the<br>
>> >> > person handling the release<br>
>> >><br>
>> >> Is there a way to automate this? Like giving you the URL of the<br>
>> >> release repository in COPR and using whatever latest package you find<br>
>> >> there?<br>
>> >><br>
>> ><br>
>> > What I think we should do is to add support that once an official tag is<br>
>> > done an official build will be triggered and done.<br>
>> > The question is can the official build flow be automated? IIRC it<br>
>> > involves<br>
>> > using tarball + signing or some other manual work which isn't<br>
>> > similar to the way nigthly rpms are built.<br>
>> ><br>
>> ><br>
>> >><br>
>> >> Martin<br>
>> >><br>
>> >> On Wed, Jun 22, 2016 at 9:44 AM, Sandro Bonazzola <<a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a>><br>
>> >> wrote:<br>
>> >> > Hi,<br>
>> >> > since it seems not clear how to get your package included in a oVirt<br>
>> >> > release, here's the procedure:<br>
>> >> > - a new build planned is communicated to <a href="mailto:devel@ovirt.org">devel@ovirt.org</a> from release<br>
>> >> > engineering team<br>
>> >> > - you as package maintainer should prepare your package to be<br>
>> >> > released<br>
>> >> > with<br>
>> >> > desired version (<a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a>, spec, whatever)<br>
>> >> > - you as packager should build your package in jenkins / koji / copr<br>
>> >> > /<br>
>> >> > whatever you use to build<br>
>> >> > - you as packager / maintainer should add your build to the release<br>
>> >> > configuration file[1] or send an email with the link to your builds<br>
>> >> > to<br>
>> >> > the<br>
>> >> > person handling the release<br>
>> >> > - if you correctly add your package to conf files, you'll have your<br>
>> >> > package<br>
>> >> > released and release notes updated.<br>
>> >> ><br>
>> >> > [1] like in<br>
>> >> > <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>
>> >> ><br>
>> >> > Thanks<br>
>> >> > --<br>
>> >> > Sandro Bonazzola<br>
>> >> > Better technology. Faster innovation. Powered by community<br>
>> >> > collaboration.<br>
>> >> > See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
>> >> ><br>
>> >> > _______________________________________________<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/mailman/listinfo/devel</a><br>
>> >> _______________________________________________<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/mailman/listinfo/devel</a><br>
>> >><br>
>> >><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Eyal Edri<br>
>> > Associate Manager<br>
>> > RHEV DevOps<br>
>> > EMEA ENG Virtualization R&D<br>
>> > Red Hat Israel<br>
>> ><br>
>> > phone: <a href="tel:%2B972-9-7692018" value="+97297692018">+972-9-7692018</a><br>
>> > irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
><br>
><br>
><br>
><br>
> --<br>
> Eyal Edri<br>
> Associate Manager<br>
> RHEV DevOps<br>
> EMEA ENG Virtualization R&D<br>
> Red Hat Israel<br>
><br>
> phone: <a href="tel:%2B972-9-7692018" value="+97297692018">+972-9-7692018</a><br>
> 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&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>