On 10 January 2017 at 12:22, Martin Sivak <msivak@redhat.com> 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 bkorren@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/