> 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 <ee...@redhat.com> wrote: > > > On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msi...@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 <sbona...@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) _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
