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

Reply via email to