[ovirt-devel] [TIPS] How to get your package released in oVirt

[Martin Sivak]

> What I think we should do is to add support that once an official tag is
> done an official build will be triggered and done.
> The question is can the official build flow be automated? IIRC it involves
> using tarball + signing or some other manual work which isn't
> similar to the way nigthly rpms are built.

Please let it live separately from the main project development
repository and its tags.. The spec file is also something that might
be oVirt specific (because Fedora, RHEL and CentOS have a different
dependencies and packaging requirements..) and should be separated
from the actual upstream tarball source release.

But a flow similar to distgit would be nice, let me release a
component any time I want (with the necessary branch based way to
ensure compatibility) and take the latest from the right branch for a
compose.

The reason I asked about COPR is that I already use it like that, I
have a special COPR project where I release optimizer bits for 3.5 [2]
and 3.6 [1] in the distgit fashion. And I have a separate project for
master tests and will have a separate project for 4.0 rpms.

[1] https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-3.6/
[2] https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-3.5/


Martin


On Wed, Jun 22, 2016 at 11:38 AM, Eyal Edri <eedri at redhat.com> wrote:
>
>
> On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak at redhat.com> wrote:
>>
>> > - you as packager / maintainer should add your build to the release
>> > configuration file[1] or send an email with the link to your builds to
>> > the
>> > person handling the release
>>
>> Is there a way to automate this? Like giving you the URL of the
>> release repository in COPR and using whatever latest package you find
>> there?
>>
>
> What I think we should do is to add support that once an official tag is
> done an official build will be triggered and done.
> The question is can the official build flow be automated? IIRC it involves
> using tarball + signing or some other manual work which isn't
> similar to the way nigthly rpms are built.
>
>
>>
>> Martin
>>
>> On Wed, Jun 22, 2016 at 9:44 AM, Sandro Bonazzola <sbonazzo at redhat.com>
>> wrote:
>> > Hi,
>> > since it seems not clear how to get your package included in a oVirt
>> > release, here's the procedure:
>> > - a new build planned is communicated to devel at ovirt.org from release
>> > engineering team
>> > - you as package maintainer should prepare your package to be released
>> > with
>> > desired version (configure.ac, spec, whatever)
>> > - you as packager should build your package in jenkins / koji / copr /
>> > whatever you use to build
>> > - you as packager / maintainer should add your build to the release
>> > configuration file[1] or send an email with the link to your builds to
>> > the
>> > person handling the release
>> > - if you correctly add your package to conf files, you'll have your
>> > package
>> > released and release notes updated.
>> >
>> > [1] like in
>> > https://gerrit.ovirt.org/#/q/project:releng-tools+topic:releases
>> >
>> > Thanks
>> > --
>> > Sandro Bonazzola
>> > Better technology. Faster innovation. Powered by community
>> > collaboration.
>> > See how it works at redhat.com
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel at ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>
>
>
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
>
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)