mesa_7_7_branch and master are becoming quite different, because of all the gallium interface changes that have been going into master, so merging fixes from mesa_7_7_branch into master is becoming less and less of a trivial exercise.
This is aggravated by the fact we are basing a release from the mesa_7_7_branch, so it's likely that we'll need to have temporary non-invasive bugfixes that should not go into master (which should receive instead the proper and potentially invasive fix). I see a few alternatives here: a) stop merging mesa_7_7_branch -> master. bugfixes should be applied to both branches. preferably by the person that wrote the patch. b) when applying a non-trivial bugfix to mesa_7_7_branch, the same person should do the merge into master, and undo any undesired change, or update for interface changes in master. Note however that it's better to give a few days between applying to mesa_7_7_branch and merging into master, to allow for wider testing, otherwise we'll be merging like crazy. c) do not apply any non trivial bugfix to mesa_7_7_branch anymore, and use a separate branch for those. I don't feel strongly about any of these alternatives for now. We'll eventually need to setup a private branch for our release so c) is bound to happen anyway. But I also think we can't keep merging mesa_7_7_branch into master like this forever -- after so much thought was put into the gallium interface changes (feature branches, peer review, etc) but whenever a mesa_7_7_branch -> master happens all sort of wrong code is merged automatically. The ideal would be to peer-review the merges before committing, but it seems difficult to do that with git, while preserving merge history and not redoing merges. Jose ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
