[Mesa-dev] so the development model is working?

Kristian Høgsberg krh at bitplanet.net
Fri Apr 30 16:54:43 PDT 2010


On Fri, Apr 30, 2010 at 7:39 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> On Fri, Apr 30, 2010 at 12:59 AM, Dave Airlie <airlied at gmail.com> wrote:
>
>>> Alex Deucher        2                     0
>> - pci ids
>
> My development pattern also favors work on master with cherry-picks to
> stable.  Usually I notice bugs when working on new code, then have to
> go back and apply to stable.  I also try and backport fixes from
> master when I see them, but that means cherry-picking.  I'd prefer
> master with cherry-picks to stable.

Let me just add a me-too here.  For me it's not so much the workflow
of checking out stable to commit the patch, after all, to cherry pick
the patch, I would have to check it out anyway (I usually only use one
checkout of mesa).  The problem for me is that I really don't want to
merge all of 7.8 into master. I just don't know what's in there or who
comitted what's there and I can't vouch for it.  When cherry-picking,
I pick just the commit that I did and understand, not a branch of
potential unrelated fixes.

The other thing, which I haven't seen brought up so far, is that a bug
sometimes requires different fixes for master and for a stable branch.
 For the stable branch you often want to take a more conservative
approach, that avoids affecting too much other code, or maybe even
back out the feature that's broken.  On the master branch, you
typically want to fix the root cause and fix it the right way however.
 In that case you simply can't merge the stable branch into master,
since you'll have two conflicting approaches to fixing the bug.

I guess I've never understood what the merging policy is supposed to
acheive?  Are we trying to avoid dropping fixes or is there something
else going on?  It sure seems like we're dropping/losing more fixes
the way things work now...

Kristian


More information about the mesa-dev mailing list