I had a quick look at that, and I *think* it's a similar approach to what we've done in 7.5 (at least for bugfixes), but it's made a little difficult to tell because there is an assumption that you know what "upward" and "downward" mean. As far as I can tell, "maint" is the lowest branch, even though in the bullet-list it appears at the top?!?... Anyway, the text is consistent with a workflow where merging stable->instable is the preferred way to propogate bugfixes into newer code.
Another thing I don't fully undersand -- they point out that dev->stable merges can't happen because they would carry all the topics in unstable over at once (ok, I guess that's what happens when we create eg. a 7.6 branch), but then they don't really say how topics *do* move to more stable branches -- and how to avoid losing any integration work done on the topic after it is merged into the unstable branch. Other questions - is there one long-lived stable branch? Is there a "maint-7.5" branch for 7.5, "maint-7.6", etc? Or does "maint" rebase somehow when a new release cycle starts? Keith ________________________________________ From: tom fogal [tfo...@alumni.unh.edu] Sent: Friday, September 04, 2009 12:33 PM To: Ian Romanick Cc: mesa3d-dev@lists.sourceforge.net Subject: Re: [Mesa3d-dev] Mesa 7.6 branch coming Ian Romanick <i...@freedesktop.org> writes: > 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. [snip] > > There are a couple of points in favour of the periodic merge approach, [snip] > >>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. [snip] > The natural work flow is [. . .] FWIW, git includes an overview of how git.git runs in gitworkflows(7). It describes a system where bugfixes are applied to the oldest possible location in history, and graduate upwards (towards instability). Cherry-picks are still used for the occasional mistakes that get applied to unstable places but should be stable. Sounds like this would require more discipline on the part of developers. Not that I'm going as far as to advocate their approach, but it does have the benefit that we know it works... else we wouldn't be having this discussion ;) -tom ------------------------------------------------------------------------------ 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
