On Tue, 2010-01-26 at 16:26 -0800, Brian Paul wrote: > Stephane Marchesin wrote: > > On Tue, Jan 26, 2010 at 15:13, Ian Romanick <i...@freedesktop.org> wrote: > >> -----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. > > > > More bureaucracy. Just what we need in our understaffed world. > > I'm not too crazy about this either. We can barely keep up with the > patches submitted for review now. I certainly don't have time to > review everything that comes along and very few other people are > reviewing/testing/committing patches either. > > My plate is already full.
One thing worth noting is how well the branch->master merges have been working. We've *never* managed to put so many fixes into the stable branch and successfully propagate them to master. Think of the hundreds of commits Vinson has made fixing errors from static analysis. The system has worked better than anything else before, but is now starting to reach its limits. That seems to me to call for a minor adjustment rather than a total overhaul. Maybe the approach should be to minimise now the amount of stuff going into the stable branch - ask Vinson to do his work on master now, for instance, and let the stable branch only take fixes for user-visible bugs, which are hopefully smaller in volume. Keith ------------------------------------------------------------------------------ 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
