-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

José Fonseca wrote:
> 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.

This was my primary argument *against* our current commit / merge model.

> 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.

It sounds like we want to copy the Linux kernel model:

- - Each developer has a local tree.
- - Each developer sends out:
   - A patch series
   - A pull request
   - A list of commit IDs to cherry-pick
- - Based on review comments, the maintainer applies the patches / pulls
the tree.

This seems like a fine plan for stable release branches.  There are
several tools available to which patches have been sent to a mailing
list but not applied.  Using one of those should fix the problem where
patches would not get cherry-picked back to stable branches.  The X
server is trying this method, and it seems to be working.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAktfdzUACgkQX1gOwKyEAw9lmwCePhLll4W5Lrv7tw7UFLYXmlni
6QUAmgPEDDdk11aESTAWy3kGF17UWx7M
=F0HU
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to