-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keith Whitwell wrote: > On Thu, 2009-09-03 at 15:13 -0700, Michel Dänzer wrote: >> On Thu, 2009-09-03 at 14:43 -0700, Ian Romanick wrote: >>> 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. >> At least in the case I assume you're referring to, it would have been >> more or less the same problem with cherry-picking, as the indentation of >> the GLX code is different between branches. I think the lesson there is >> to resist the temptation of whitespace-only changes, no matter how much >> 'better' the result may appear. > > There are a couple of points in favour of the periodic merge approach, > firstly that if people really care about producing a high-quality, > release-quality, QA'd Mesa-7.6, then you'll find yourself: > - testing the 7.6 branch > - spotting bugs on the 7.6 branch > - developing and committing fixes on the 7.6 branch, > - repeat for the entire supported life of the driver. > >>From that point on, it is natural to want to be 100% sure that bug-fixes > have been preserved, and periodically merging the 7.6 branch to master > guarantees that none of those bugfixes will be lost/forgotten. > > This doesn't prevent people who want to work a different way from > developing bugfixes on master and cherry-picking them to stable, but > it's not a natural workflow for the case where a bug is spotted on > stable and needs to be fixed on stable.
That depends entirely on whether or not the bug also exists on master. The natural work flow is to fix something on an unstable branch, make sure it doesn't cause unrelated regressions, then, when you're sure it's actually stable, move it to the stable branch. I had suggested in an earlier e-mail that these unstable branches be short-lived topic branches. The move to the stable branch (and to master) would then just be a merge from the topic branch. I think this would resolve all of the issues. For the stable branch, this would also give a better opportunity for review. These all seem like good things, right? Is it worth trying something different for one release? > It seems the objections so far to this practice are that: > 1) you get repeat mail-outs of merged fixes It isn't just that. The commits show up multiple times at different places in the revision history. This is, at best, confusing. It's not clear to me what it means when, for example, you're bisecting. Having commits move both ways across branches is just broken. It's not the way GIT is intended to be used, so it should come as no surprise that things get ugly when it's used that way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhY78ACgkQX1gOwKyEAw/UPACfe+e/RBfLq0xdKNebgl6bIt1Z xA4AoJp9GUvAssAoxx7kRliC45k9vIhV =ASeP -----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
