"Jeff Squyres (jsquyres)" <jsquy...@cisco.com> writes: > Meaning: we deliberately chose not to change the development style of > the community to "develop on release branch" when we moved to git.
Understood. It's your choice, but workflow is a big feature of Git. >> 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. You could push release tags to open-mpi/ompi without pushing the branches. >> 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. If integration branches were merged upward, "git describe" would yield names like v1.8.3-84-g51a7c90, which tells you immediately that it's 84 commits "ahead" of v1.8.3. > Put differently: the dev tag is solely for ordering of nightly snapshot > tarballs. It affects git describe output as a side-effect and when someone writes the mailing list with a bug in a year-old nightly snapshot, you'll need to query the repository (or have a better memory than me) to have any idea what they're working with. Perhaps you are blessed with users that don't do things like this.
pgps5ALZ4CF9h.pgp
Description: PGP signature
