On Wed, Jun 22, 2016 at 2:17 PM, Martin Sivak <[email protected]> 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 <[email protected]> wrote: > > > > > > On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <[email protected]> > 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 <[email protected]> wrote: > >> > > >> > > >> > On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <[email protected]> > >> > 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 < > [email protected]> > >> >> 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 [email protected] 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 > >> >> > [email protected] > >> >> > http://lists.ovirt.org/mailman/listinfo/devel > >> >> _______________________________________________ > >> >> Devel mailing list > >> >> [email protected] > >> >> 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)
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
