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

[Martin Sivak]

> That's not automation, its just you (human) building the official build in
> COPR
> rather in jenkins no?

It is automated enough for me, I just upload (the equivalent of
tagging) the srpm and it builds it for all platforms. It is then
automatically released in the project repository.

COPR is not just a build system, it also exposes repositories for
projects and you can easily use it from dnf.

It is also much easier to use than what we have, because I can have a
separate configuration for different releases and distributions. This
is much harder when the release is directly tied to the upstream
source repository. And I am using upstream in the project source sense
here, oVirt is downstream in that sense (as is Fedora or RHEL).

Martin

On Wed, Jun 22, 2016 at 12:59 PM, Eyal Edri <eedri at redhat.com> wrote:
>
>
> On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <msivak at redhat.com> wrote:
>>
>> > 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.
>
>
> That's not automation, its just you (human) building the official build in
> COPR
> rather in jenkins no?
>
> Which again leaves us with the problem of maintainer not aware he needs to
> builds/not synced/away....
>
> If we can reach a common ground for all projects on how to use a single (or
> at least a small group)
> of automation scripts that will do a formal build, then similar to what we
> do with nightlies we can collected
> them into a 'pre' repo which is candidate for release.
>
>
>
>
>>
>> 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)
>
>
>
>
> --
> 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)