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
