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