> While packages are separate entities and have independent life cycles, > we still need a way to compose and test oVirt as a whole. And the > responsibility to determine which version of the package goes into > which oVirt release should, in many cases lay on the shoulders of that > package maintainer. > > Having distgit-like solution can be simple enough, but it sounds to me > like an overkill in many cases. > > How would you suggest to solve this?
Well, what about another text file in the automation directory? use-for.txt with ovirt-x.y and wildcards? > Travis never concerns itself with full system composition and > integration testing, so this is not a useful analogy at all. Oh, but it does.. you can configure publishers ans webhooks in the .travis.yml file. I commonly build a project, create a docker image using the built bits and deploy to my VPS (using a branch name check). Martin On Tue, Jan 10, 2017 at 1:06 PM, Barak Korren <[email protected]> wrote: > On 10 January 2017 at 12:22, Martin Sivak <[email protected]> wrote: >> Hi, >> >> all of that makes sense except this: >> >>> When it comes to branches, I think the way to go is to standardize >>> branch names. That standard should probably be something like >>> 'ovirt-4.0', 'ovirt-4.1', etc. Alternatively we could use something >>> like 'ovirt(-.*)?-.4.0' or (<repo_name>-4.0) to accommodate existing >>> conventions like the engine`s. >> >> Do not force a branching model on me, please. We have small packages >> that either do not need any branches at all or we create the Z stream >> branch on as needed basis only. For example: mom does not need >> branches it is always compatible, ovirt-optimizer ever had only one Z >> stream patch in its history... >> >> Please start treating packages as separate entities with independent >> development space. You are trying to workaround the lack of distgit by >> forcing us to play with our upstream source code repository. You >> should stop doing that as you will get into trouble once a first >> non-gerrit project is accepted to oVirt. (And we have couple of >> project where GitHub is the primary platform already) > > While packages are separate entities and have independent life cycles, > we still need a way to compose and test oVirt as a whole. And the > responsibility to determine which version of the package goes into > which oVirt release should, in many cases lay on the shoulders of that > package maintainer. > > Having distgit-like solution can be simple enough, but it sounds to me > like an overkill in many cases. > > How would you suggest to solve this? > >> The way this is done on Travis for example is much better. Pushes to >> all branches are monitored and branches with no .travis.yml (or >> automation dir in our case) are ignored. > > Travis never concerns itself with full system composition and > integration testing, so this is not a useful analogy at all. > > > -- > Barak Korren > [email protected] > RHCE, RHCi, RHV-DevOps Team > https://ifireball.wordpress.com/ _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
