On Oct 17, 2014, at 6:41 AM, Jed Brown <j...@jedbrown.org> wrote: >> The ompi repo only contains the master branch. Releases are not made >> from master, and therefore it doesn't make sense to tag it with >> release tags. master is therefore not (directly) related to any given >> release. > > You can have tags in the repository without the branches, though I think > it's useful for a contributor to > > git checkout -b my/bug-fix maint-1.8 > > instead of making a patch off 'master' that needs to be back-ported to > the release. The usual model is that one merges "upward" from the > maintenance branches to 'master'.
We talked about this when we converted to git. For better or for worse, this model is just not how the OMPI community has worked. We typically develop on the trunk/master and then port to the release branches. Developing directly on a release branch usually only occurs when there's a bug that only exists on the release branch (and not on trunk/master). Meaning: we deliberately chose not to change the development style of the community to "develop on release branch" when we moved to git. > But regardless, isn't it valuable to be able to query things like this? > > git log v1.8.0..master ompi/mpi/c/iallreduce.c > > git branch -r --contains $bug_fix_commit > > Seems to me that most people cloning open-mpi/ompi will want to fetch > From open-mpi/ompi-release regularly so they can have this context. Agreed. If github would implement per-branch push ACLs, then we'd squash down to a single repo, and all this would be easier. But given the relative inexperience with git in our community (which is noticeable via some mistakes on the ompi repo already!) and our history of only allowing regulated commits to release branches, we chose the (admittedly somewhat awkward) 2-repo model. > That number will get big later Of course. > and it deprives you of context when you > have no idea whether "dev-BIGNUMBER" is earlier or later than a given > release. (Does it have those features/bugs or not?) Even if OMPI was just in one git repo, the number of commits on master since dev is unrelated to a given release. Put differently: the dev tag is solely for ordering of nightly snapshot tarballs. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
