On 2015-09-28 10:44, Adam Coldrick wrote:
On Sat, 2015-09-26 at 08:35 +0100, Paul Sherwood wrote:
> The idea would be that the baserock dir (for example) would contain
> d--------- strata
> d--------- systems
> and this would include the definitions of our core integration set
> (build-system*, cross-bootstrap*, devel*, minimal*).
> The openstack dir (for example) would contain systems and strata
> specific to openstack. Those systems and strata would refer to
> and components from the baserock set (or override them with their
> things) as needed.
Where would things which aren't "core" but used in various places be
kept? I have in mind things like the databases, django and apache
strata, but there are probably many other such things too.
Unclear. Maybe examples/miscellaneous at the same level as baserock dir
Also, do you have an idea on how the overrides should work? It seems
me that we'd either need to modify the build tool to support an
`override:` field or also override everything that depends on the
I'm against overrides. If downstream wants their own 'version' of, say
python-utils they have two options:
- modify our upstream version, and maintain that modification
- create their own in a separate dir, and refer to that.
> This would mean that we can treat different subdirs in specific
> depending on the requirement e.g.
> - baserock gets integrated constantly against mainline kernel,
> and others
> - genivi gets six-weekly refresh
> - openstack maybe gets six-monthly release to coincide with mainline
If this is implying that we would only test that OpenStack works on
of the "baserock" strata every six months I disagree with that. I'd
No, not at all. Our openstack can be in CIAT, validated every day with
automated integration. But OpenStack itself releases on a six-month
cadence as i understand it, so the openstack specific functionality
should be re-integrated in some way that aligns with OpenStack itself,
not dictated by any other (baserock-determined) release schedule.
in other words, we can consider updating swift, cinder, horizon and
other things on a six-monthly schedule, but our current versions of
these things could be validated continually against changing system
components in the meantime.
to be continually checking everything we "support" in our
definitions works if possible.
> This approach would also allow us to recommend that downstream users
> create their own subdirectory or subdirectories, to contain their
> custom definitions. If they keep their deltas separate I think this
> would reduce the incidence of merge conflicts for them.
This would be great, and if possible maybe we could advise this even
without/before this rearrangement?
Absolutely. But hopefully we can achieve a rearrangement relatively