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

Wed Jun 22 12:06:04 UTC 2016

On Wed, Jun 22, 2016 at 2:17 PM, Martin Sivak <msivak at redhat.com> wrote:

> > 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.
>

Again, you're thinking on a small group of maintainers that might think as
you,
less on oVirt as a sum of 60+ different projects.

While what you are suggesting might be an improvement of existing system,
I am thinking on a full automated solution for all projects that will be
handled
in a similar way to nightlies and verification done on CI.

>
> 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)
>

-- 
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160622/c91dcad4/attachment-0001.html>