-----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
