On Wed, Jan 27, 2010 at 12:02, Ian Romanick <i...@freedesktop.org> wrote: > -----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. :)
For example see right now on irc, #xorg-devel : < aaronp> keithp: Are you around? There are a couple of pretty critical fixes that are awaiting push to master, most notably "Fix source pictures getting random transforms" from Pierre-Loup. Stephane ------------------------------------------------------------------------------ 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
