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