… > > > Hi everyone! > > > > > > > > > In an effort to improve the project workflow and ease the maintenance and > > > improve the quality of the project releases I want to propose start > > > working > > > towards automated builds and releases, the main ideas are the following: > > > > > > > > > * Stop building differently for release and non-release: > > > - Building only once, testing what you build and release what you test > > > - Don't use two different version strings, one for testing and one for > > > release
+1 > > I'm not really comfortable in releasing rpms like > > ovirt-host-deploy-offline-1.4.0-0.0.master.20150528094853.git7428372.el7.x86_64.rpm > > as GA release. > > This can be automated to don't add the extra info to the release in case of a > tag creation, but that means that you have to run all the testing again when > pushing the tag, ideally it would block the tag creation, so if it fails it > would not tag the build but we don't have any gating system so right now it > would have been done after the tag is pushed, so you'd have to force tag > again > (creating rpms with the same version that contain different code) or bump the > tag (making it feasible that the first released version is not the lowest > tag, > for example, that the first release 4.17.* vdsm to be 4.17.5 instead of > 4.17.0 > because it took 5 retaggings to pass the tests) I'd favor the solution where we increase the tags until we've got the final build. Having different rpms with the same NVR should not happen. - fabian > Extra metadata can be added to the rpm: > branch: master > commit_id: 7428372 > > so the build passed QE and > 1) file names of the rpms can be changed to standard NVR > 2) createrepo is running > 3) repo is validated repoclosure > > > > > > > > > > > > > > * Automate the build process, and the release process, directly getting > > > the > > > code from the repos (no manual build tarballs) > > > > This is fine for me, provided that the automated build start from a tagged > > version and become something like ovirt-host-deploy-offline-1.4.0-1 > > > > > > > > > > * Adopt semantic versioning, it's a lot more meaningful than the current > > > scheme > > > and fits very well with the above points > > > > No much experience in using semantic versioning, will take a look. > > > > > > > > > > > > > > > > This will ease and lower the maintenance and the extra work required by > > > maintainers, release engineers (sandro) and infra itself by making > > > releases as > > > easy as hitting a button at any time. That will allow us to lower the > > > time > > > features and fixes get to the users, and deliver packages and builds that > > > have > > > passed through all the tests we have, instead of rebuilding on another > > > env, at > > > another time, by someone else, and passing only manual testing. > > > > +1 > > > > > > > > > > > wdyt? > > > > > > > > > > > > > > > _______________________________________________ > > > Devel mailing list > > > Devel@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/devel > > > > > > > > > -- > > Sandro Bonazzola > > Better technology. Faster innovation. Powered by community collaboration. > > See how it works at redhat.com > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > _______________________________________________ > 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 > _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
