[I'm renaming this email thread] Ian Romanick wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric Anholt wrote: >> On Fri, 2009-09-11 at 10:37 -0700, Ian Romanick wrote: >>> Eric Anholt wrote: >>>> Module: Mesa >>>> Branch: master >>>> Commit: 7c0152fbaeb21ab423a9de339b85c54d1713432b >>>> URL: >>>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=7c0152fbaeb21ab423a9de339b85c54d1713432b >>>> >>>> Author: Eric Anholt <[email protected]> >>>> Date: Thu Sep 10 09:44:30 2009 -0700 >>>> >>>> i965: Enable loops in the VS. >>>> >>>> Passes piglit glsl-vs-loop testcase. >>>> >>>> Bug #20171 >>> I see this went into master. Is this also a candidate for 7.5 or 7.6? >>> If so, it should have gone there first. I can take care of the >>> cherry-picking and merging while you're on vacation. >> For the record, I hate that development model. It means that I have to >> first identify the earliest branch a change could apply to before >> working. Or I have to do a dance more complicated than just >> cherry-picking after the fact to land my change after I develop it on > > I somewhat agree. However, this analysis needs to be done at some point > anyway. Right? It either gets done up-front, or it gets done when > trying to determine whether to cherry-pick back.
As Mesa project leader, I *very* seldom tell people how to work or what to do, but in this case I'm strongly advocating the "fix bugs on the bug-fix branch and merge forward" model. The main problem right now is we have 3 active branches (master, 7.6 and 7.5) and it can be confusing. I wasn't really planning on another 7.5.x release until Eric cherry-picked a bunch of changes to it. I'm still not sure I'll release 7.5.2 in any case. Ian, I'd be happy to see the 7.6 release made at any time. At that time, I'm inclined to abandon the 7.5 branch. Then we'll just have master and one branch to think about. That's pretty easy. I've been finding the "work on a branch" approach to be simpler than the cherry-picking model. I can fix a bug in one place then pretty much forget about it knowing that the branch will periodically get merged forward and carry along all my fixes. There's seldom conflicts, and off-hand, I can't think of an case where a fix from the 7.5 branch (for example) has broken master. >> master. It hurts the idle, "how hard will this little thing be" >> experimenting that I do a lot. And given the number of commits of >> merges with conflicts we're seeing, I'm doubting that the merges forward >> are seeing much testing. > > I agree with the testing comment 100%. > > Testing in Mesa has always been weak, and the branch juggling is just > exacerbating the issue. I'd say Mesa testing is better than ever with Intel's and VMware's continuous testing (and kitware/vtk dashboard), new piglit and glean tests, etc. But as far as testing goes, I haven't found the branching model to cause any more disruption than cherry-picking. > Perhaps we should have a session at XDC to discuss this. Unfortunately, I won't be there. >> I much prefer periodically analyzing my area and cherry-picking many >> patches after they've had a chance to settle, regression testing the >> batch all at once, and giving stable something that works. > > This echoes the arguments that I made when the branching discussion > first happened. The counter-argument that was made, which does have > merit, is that this analysis and cherry-picking either doesn't happen or > happens eons after the code was originally committed. By that time > nobody knows if it should be brought back or not. There were several > patches that I asked people about for 7.5, and nobody had any idea. Yeah, cherry-picking is certainly useful sometimes, but it seems like a very ad-hoc way to apply changes to multiple branches. Fixes can get lost, they appear in multiple branches with different commit IDs, etc. The branch merge model just seems so much more organized and safe. Eric, I'm sorry to upset you with this policy (I really appreciate all the good work you do) but I'd like to ask you to try the branch model for a while. If it really turns out to be a big problem for us (which I doubt) we could revisit the policy when the 7.7.x branch is created. -Brian ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
