[TIPS] How to get your package released in oVirt
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@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
- 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? Martin On Wed, Jun 22, 2016 at 9:44 AM, Sandro Bonazzola <sbonazzo@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak@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?
Perhaps it works now as-is, need to see how repoman handles your specific link. But do we really want this? Don't you think we should have a place saying "In release X.Y.Z, we used packages from the following locations", and have stable "following locations" that can be reviewed retroactively if needed?
Martin
On Wed, Jun 22, 2016 at 9:44 AM, Sandro Bonazzola <sbonazzo@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Didi
On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak@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
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@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
person handling the release - if you correctly add your package to conf files, you'll have your
On Wed, Jun 22, 2016 at 9:44 AM, Sandro Bonazzola <sbonazzo@redhat.com> wrote: the 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@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)
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@redhat.com> wrote:
On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@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)
On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <msivak@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@redhat.com> wrote:
On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@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)
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@redhat.com> wrote:
On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <msivak@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@redhat.com> wrote:
On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@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)
On Wed, Jun 22, 2016 at 2:17 PM, Martin Sivak <msivak@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@redhat.com> wrote:
On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <msivak@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@redhat.com> wrote:
On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak@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@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@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)
participants (4)
-
Eyal Edri -
Martin Sivak -
Sandro Bonazzola -
Yedidyah Bar David