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