-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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.
Oh I know! Actually applying software engineering principles to a large software project is just stupid. ;) We either want code reviews or we don't. There is no option of wanting code reviews without the effort of reviewing code. This is, literally, one of those "you can't have your cake and eat it too" situations. We've used "understaffed" as a justification for seat-of-the-pants development for way, way too long. Applying controls to a stable release branch is just common sense. For a project this size, Mesa is alone in not applying such controls. >> 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. > > Really? I see patches re-re-re-sent and forgotten all the time. That has been a (big) problem in the past. I think most of the problems that people saw with that were from before the patch tracking tool was used. If it's still a problem now, I blame Keith, and I doubt he would disagree. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAktgm8UACgkQX1gOwKyEAw9EdQCgl9S/Sl5mYcnx9Mjw9YdRVDSl dSAAn0TX5HlsM8rRfXcmLrUMOtkb9iYs =3leL -----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
