We tried a number of different approaches internally and concluded that the "commit to master then cherry pick to branch" model tended to work out best for constantly evolving software like Mesa.
The downside of a "branch first" approach is that you need to know whether a change is going into the branch *before* committing it anywhere. This would work OK if every commit were emailed to the list for a decision about whether it should go into branch+master or only into master, but since most of the changes are direct commits it seems like a "commit to master then decide if it should also go into the branch" model would work best. -----Original Message----- From: Ian Romanick [mailto:i...@freedesktop.org] Sent: Thursday, September 03, 2009 5:43 PM To: Brian Paul Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Mesa 7.6 branch coming -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brian Paul wrote: > Ian Romanick wrote: >> >> I'm intending to create a mesa_7_6_branch tomorrow (Friday) morning. >> As usual, this branch is intended for bug fixes leading to a 7.6 release. >> >> I'm open to discussion, but my preference is that the branch be used >> in the following way: >> >> - Bug fixes that will be in master and the branch be committed to >> master, then cherry-picked to the branch. >> - Bug fixes that will only be in master *or* the branch be >> committed directly to master or the branch. >> >> By whatever means, I want to avoid the situation that we're currently >> in with the 7.5 branch. We have numerous cases of patches being >> cherry-picked and merged both ways. This results in same patch >> showing up multiple times in the master commit log. Patches should >> flow in one direction through branches. >> >> Opinions? > > I prefer the 'commit bug fixes to the stable branch then periodically > merge the branch to master' approach. There are a couple problems with that approach. 1. It's different from every other open-source project that uses GIT. People who also contribute to other projects will routinely botch this just because it's the odd man out. 2. It becomes increasing difficult to merge (as opposed to cherry-pick) from one branch to the other as the branches diverge. Michel has run into this. The branch-merge model seems to work well in projects where all development happens on topic branches or maintainer subsystem branches. In those cases no development happens on master. Things only get to master by way of other branches. At least a few people are working on Mesa in that manner already. Should we switch? It seems like it could work. > That's the model I (and the other VMware people) have been following > with the 7.5 branch. Unfortunately, it seems that few other Mesa > developers take the time to do the same. Some bugs (esp DRI driver > bugs) seem to get fixed on master but never get into the stable > branch. When we have to cherry-pick fixes to the 7.5 branch, that > results in the "double patches" you mentioned. > > As long as I'm complaining: it would be nice if bug fixes were more > often documented in the docs/relnotes*.html files too. People like to > know what's fixed from one release to the next. I don't have time to > do that for everyone else. I think the right solution here is to automate the process. Most people are pretty good about putting bug numbers in commit messages. We ought to be able extract that information from the GIT log. Since there are so many commits to Mesa for each release, I do NOT think we should include the whole shortlog as some other projects do. I'll see if I can come up with a script to do this. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqgOGsACgkQX1gOwKyEAw9+ogCgnjI67wrZWwe/qRa7w63oPrPk SroAn2+759FAMNs81RL4uDh4gOSz4DSK =M5+q -----END PGP SIGNATURE----- ------------------------------------------------------------------------ ------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
