On 20.11.2012 17:28, Hugh Brock wrote:
On Tue, Nov 20, 2012 at 05:12:15PM +0100, Giulio Fidente wrote:
hi Steven
On 11/20/2012 05:04 PM, Steve Linabery wrote:
It's certainly not a 'proper' release, with docs, release announcement,
description of what other components are required (factory, et al).
agreed, I was trying to find out if and how the tags/branches of the
components relate to each other (inclunding factory, oz, cli, maybe TIM
at some point in the future)
Also, do you see the idea of tagging all the components with the same
tag a valid approach or are there different suggestions?
What I would like to see on an actual upstream release is:
1) create maintenance branch and tag on that branch
2) bump version number on master branch for ongoing development
to be honest, I'm not sure what are the best practices for such a
complex project where we want to merge the development efforst from
different components, but your looks to me a good approach
devs, any hint on this?
It's a tough problem.
Ultimately I think three things need to happen.
1. Each separate upstream needs to be fully testable in isolation from
its dependencies -- i.e. fully mocked out. We have made some progress
towards this, I'm not sure if it's complete or not.
2. An upstream with dependencies needs to be integration tested against
known-good versions of its dependencies. It's probably a Release Cabal
function to decide what the "stable" versions of deps are and approve
revisions to those as part of release planning.
3. As far as automated testing goes, it seems to me we ought to
continuously test changes to each upstream project, but not more than
one at a time. In other words, Conductor gets CI run against HEAD, but
with known-good deps. If Conductor requires a dependency updated (newer
Deltacloud, e.g.) then that Deltacloud version should become the
known-good for the whole project -- or the Conductor dependency update
shouldn't be allowed in.
Does that make any sense?
It does to me. Seems like a lot of testing, but since we are splitting into
smaller subprojects, it might be necessary. So far Aeolus was bunch of
relatively stable components with Conductor being the only unstable one, so
point (3) was probably not necessary till now. But with Tim and Alberich being
cut out and Winged Monkey joining soon, there are going to be more connections
between potentially unstable projects, so (3) seems to me as a good idea too.
(1) is the tests we already have, but I wonder how (2) is going to be done.
Will it be run on developers' machines, or only on CI? Are we going to enforce
that code not passing (2) doesn't get pushed? (I think Travis won't let us do
(2), will it?)
J.
--Hugh
