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 > 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. > Where do tools live? > Wherever we want them to. > 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. > 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) > > I expect the outcome of this discussion to be > > relevant no matter what we eventually wind up doing, do please leave your > > opinions about migrating to a different org somewhere else. > > Agreed, that's an entirely separate discussion. > > _______________________________________________ > Crowbar mailing list > Crowbar@dell.com > https://lists.us.dell.com/mailman/listinfo/crowbar > For more information: http://crowbar.github.com/ >
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
