Victor Lowther (victor.lowt...@gmail.com) wrote:
> On Fri, Jan 3, 2014 at 5:33 AM, Adam Spiers <aspi...@suse.com> wrote:
> > Victor Lowther (victor.lowt...@gmail.com) wrote:
> > > This is intended to work as a starting point for a discussion of what tool
> > > we should use to use to track inter-repository dependencies for CB2.0 in
> > > the opencrowbar org.
> >
> > Before evaluating the tools I think it would be worth trying to
> > clarify the requirements. For example, all the approaches you list
> > seem to assume that there will only be dependencies from a single
> > superproject repository onto multiple slave repositories, but why is
> > it safe to exclude the possible need to track dependencies between
> > slave repositories?
>
> Then you are assuming too much. None of the tools I mentioned enforce such
> a relationship between git repositories
OK, maybe I didn't express myself clearly enough then, or maybe we
are talking about different types of dependencies.
I assumed that by "inter-repository dependencies" you were talking
about dependencies at the version control layer, e.g. one of the
following:
- "commit X in repository A requires commit Y in repository B"
- "commit X in repository A requires commit Y or newer in repository B"
- "branch X in repository A requires commit Y in repository B"
- "branch X in repository A requires commit Y or newer in repository B"
- "tag X in repository A requires commit Y in repository B"
- "tag X in repository A requires commit Y or newer in repository B"
- "commit X in repository A requires branch Y in repository B"
- "branch X in repository A requires branch Y in repository B"
- "tag X in repository A requires branch Y in repository B"
- "commit X in repository A requires tag Y in repository B"
- "branch X in repository A requires tag Y in repository B"
- "tag X in repository A requires tag Y in repository B"
(Probably not all of these would be useful, but I'm just listing them
now for clarity, to help us avoid talking at cross-purposes.)
These types of dependencies are obviously very different in nature to
the crowbar.yml types of dependencies such as "barclamp-nova requires
barclamp-keystone".
So are you talking about the first type of dependency or the second,
or both, or something else?
With regards to the first type of dependency listed above
(i.e. version control layer):
./dev, git submodule, and git subtree, and gitslave *all* assume a
topology which involves a single parent repository and one or more
child repositories. I'm not sure about gitslave, but for the other
three, version control layer dependencies can only be expressed from
the parent ("superproject" as gitslave calls it) onto children
(e.g. to define a "snapshot" representing a particular release), not
between children. So my question was: is this limitation safe, or
might it get in the way later on? The answer may well be "yes, it's
safe"; I just wanted to raise awareness that adoption of any of the
tools you proposed will impose that limitation.
> > What do these repositories contain?
>
> Source code, docs, and metadata.
>
> > Multiple barclamps in the superproject and one per slave?
>
> Doesn't matter for the purposes of this conversation.
It does, because ./dev currently assumes no barclamps in the
superproject and one per slave whereas the other tools you proposed
don't, so if you want to achieve something different to the current
layout then that will certainly impact the decision whether to
continue using ./dev or not.
> > Where do tools live?
>
> Wherever we want them to.
Will the superproject be release-specific or not? Development of
./dev and its associated files was held back by the fear of breaking
reproducible builds for older releases. But then keeping any future
repository "meta" tool in a separate repository to the build toolchain
should alleviate this problem.
> > Is there a genuine need to track the dependencies using git _meta_data,
> > or could it be done by representing them within (say) a text file
> > which is then tracked by git, in the same way that bundler does it
> > with a Gemfile?
>
> That is an implementation detail for the tool in question. gitslave
> requires such a file, the dev tool requires several such, subtrees don't
> and we would need to wrap with a tool that does, and git submodules (post
> 1.8.2) have the proper support baked right into git.
Right.
> > I have a strong preference for reusing existing technology over
> > rolling custom tools. For example, packaging barclamps as gems would
> > provide the functionality of the whole gem/bundler ecosystem for free,
> > which AFAICS would in one stroke solve the whole problem.
>
> I don't see how introducing a packaging conversation here is useful, unless
> you prefer downloading a gem over cloning a repo when you want to hack on
> some random ruby project (as opposed to just using it)
Yes, I *hugely* prefer that - that's the whole point! If dependencies
are available as gems then this whole discussion becomes a non-issue.
Example advantages:
- Any barclamp repo could easily be unit-tested standalone in Travis
simply by ensuring its Gemfile expressed the right dependencies
(e.g. on the core framework and barclamp gems), rather than the
awful https://github.com/crowbar/travis-ci-crowbar tree flattening
hack we were forced to build previously, which was never able to
automatically test pull requests.
- Dependencies could be expressed using version numbers adhering to
semantic versioning, which gives much more flexibility during
testing than a monolithic approach which insists git cloning an
exact set of commits/branches/tags from a set of remotes chosen
by an opinionated tool.
- Doesn't reinvent any wheels.
- Proven technology already adopted by the whole Ruby community.
- Everyone already knows bundler / Gemfile etc. very well => very
shallow learning curve => more welcoming for newbies.
Packaging and dependency handling are NOT mutually orthogonal problems.
_______________________________________________
Crowbar mailing list
Crowbar@dell.com
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/
