On Oct 17, 2014, at 9:51 AM, Jed Brown <j...@jedbrown.org> wrote: > "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.
Jed, I initially advocated for a merge-based workflow when we were planning the transition to Git, but others in the community felt that it would be too painful to simultaneously learn a new VCS and invert the flow of development. I'm still not 100% sure that sticking to the cherry-pick workflow was really the right call, but I've made peace with it for now. We can certainly live with this workflow for a while and change again later if desired. Separating the shocks to non-git-comfortable developers is a good thing, IMO. >> 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. I'm not sure this is less confusing. It gives the illusion that "ompi" contains all of the release development as well, but in reality you need "ompi-release" to get anything beyond the latest tagged release. >>> 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. You're not wrong about the advantages of a merge-based workflow. I just don't think it changes what the community is choosing to do right now. >> 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. Checking the repo isn't particularly onerous, IMO. It's a lot easier than searching old bug tickets, which you're also likely to need to do when dealing with bugs reported against old snapshots. Also, there's almost no scenario where a user should be reporting bugs against a years-old "master" snapshot. Snapshots from the release branches have more useful names (e.g., v1.8.3-39-gd07d53e). -Dave
