José Fonseca wrote: > On Wed, 2010-01-27 at 00:59 -0800, Keith Whitwell wrote: >> 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. > > Yes. I agree. > > Indeed reviews only work if there are enough reviewers, and the review > traffic is pretty overwhelming as it is. I should have thought of that > before mentioning it. > > BTW, Brian thanks for all the hard work you've been doing on taking > patches. I should and will try to do more on this subject. > >> 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. > > Yes, that's probably a good compromise.
I've already asked Vinson to switch over to master for his clean-ups. -Brian ------------------------------------------------------------------------------ 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
