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