Re: [Mesa3d-dev] mesa_7_7_branch -> master merges

Re: [Mesa3d-dev] mesa_7_7_branch -> master merges

[tom fogal]

This bounced, it seems because Jose's [1] name is not representable in
8bit ASCII (some header wasn't, at least).

I'm not cc'ing Mesa to avoid spamming everyone.  I'm not sure
non-subscribers can post there anyway.  Jose or myself will forward
along any relevant discussion...

[1] sorry for misspelling it there..

------- Forwarded Message

From: tom fogal <tfogal@alumni.unh.edu>
To: José Fonseca <jfonseca@vmware.com>
cc: mesa3d-dev <mesa3d-dev@lists.sourceforge.net>, git@vger.kernel.org
Subject: Re: [Mesa3d-dev] mesa_7_7_branch -> master merges 
In-Reply-To: Your message of "Mon, 25 Jan 2010 18:14:24 GMT."
             <1264443264.3029.255.camel@jfonseca-laptop> 
References: <1264424650.3029.155.camel@jfonseca-laptop> <auto-000021765525@sci.utah.edu>  <1264443264.3029.255.camel@jfonseca-laptop> 
Date: Mon, 25 Jan 2010 12:04:00 -0700

I think we've touched on a core git workflow issue here, and its likely
others have hit this && have a solution, so I've added the git ML to
the CC list.

Git: the situation in this repo is a fast-moving master that is
including many changes to internal interfaces.  Stable branches just
get bugfixes, and are periodically merged to master.  However, the more
the heads diverge, the more difficult it is for a bugfix to merge into
the head.  The major issue is that more experienced developers should
really weigh in on these merges, because they tend to automagically
undo some of the interface changes.  Yet during such a delay, master
inevitably moves, and the bugfixer has to do even more work to "redo"
the merge (and potentially get more review!).

Of course, if there are two bugfixers trying to make separate changes
in the same time period, this gets worse.

Is there a workflow that can solve this issue?

 writes:
> On Mon, 2010-01-25 at 09:52 -0800, tom fogal wrote:
> > writes:
> > [snip]
> > > 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.
> > 
> > Google has developed an infrastructure to do peer review using git.
> > `Gerrit':
[snip]
> Review infrastructures are nice. I'd have some bias towards
> http://www.reviewboard.org/  by the similar reasons ;)

Heh, yeah I can understand the bias ;)

Personally, I'm not keen on a review tool I can't use from the command
line, or at least not-the-web.  Then again, my reviews wouldn't really
be important in Mesa, so my opinion is irrelevant here ;)

> But automated infrastructures aside, my worry with reviewing merges is
> the actual constraints that git has. For example, let's suppose the
> following scenario:
> 
> 1) Developer A merges a stable branch into master.
> 2) After spending a bunch of time fixing conflicts the best he can, he
> emails the patch to mesa3d-dev for peer review.
> 3) Developer B checks in a change into master.
> 4) Developer A takes feedback from list, updates the code, and commits.
> 5) Developer A cannot push because remote head has moved.
> 
> So what can Developer A do now?
>
> a) Redo the merge, using the new master head.
> b) Rebase the merge on top of the new head (I'm not sure it works, or
> that it preserves branch history)
> c) Double merge, i.e., merge its local head with the new master head.

Hrm, I was thinking of some sort of staging branch, but I can't think
of a good way to make it work.  The crux of the issue seems to be that
a developer needs to somehow give a version control promise that they
will do the merge, even if the merge isn't done yet, because otherwise
anyone else coming afterwards will duplicate the work (potentially
incorrectly).  That would mean some kind of lock though, which sounds
like a terrible idea...

- -tom

------- End of Forwarded Message

Re: mesa_7_7_branch -> master merges

[tom fogal]

I think we've touched on a core git workflow issue here, and its likely
others have hit this && have a solution, so I've added the git ML to
the CC list.

Git: the situation in this repo is a fast-moving master that is
including many changes to internal interfaces.  Stable branches just
get bugfixes, and are periodically merged to master.  However, the more
the heads diverge, the more difficult it is for a bugfix to merge into
the head.  The major issue is that more experienced developers should
really weigh in on these merges, because they tend to automagically
undo some of the interface changes.  Yet during such a delay, master
inevitably moves, and the bugfixer has to do even more work to "redo"
the merge (and potentially get more review!).

Of course, if there are two bugfixers trying to make separate changes
in the same time period, this gets worse.

Is there a workflow that can solve this issue?

 writes:
> On Mon, 2010-01-25 at 09:52 -0800, tom fogal wrote:
> > writes:
> > [snip]
> > > 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.
> > 
> > Google has developed an infrastructure to do peer review using git.
> > `Gerrit':
[snip]
> Review infrastructures are nice. I'd have some bias towards
> http://www.reviewboard.org/  by the similar reasons ;)

Heh, yeah I can understand the bias ;)

Personally, I'm not keen on a review tool I can't use from the command
line, or at least not-the-web.  Then again, my reviews wouldn't really
be important in Mesa, so my opinion is irrelevant here ;)

> But automated infrastructures aside, my worry with reviewing merges is
> the actual constraints that git has. For example, let's suppose the
> following scenario:
> 
> 1) Developer A merges a stable branch into master.
> 2) After spending a bunch of time fixing conflicts the best he can, he
> emails the patch to mesa3d-dev for peer review.
> 3) Developer B checks in a change into master.
> 4) Developer A takes feedback from list, updates the code, and commits.
> 5) Developer A cannot push because remote head has moved.
> 
> So what can Developer A do now?
>
> a) Redo the merge, using the new master head.
> b) Rebase the merge on top of the new head (I'm not sure it works, or
> that it preserves branch history)
> c) Double merge, i.e., merge its local head with the new master head.

Hrm, I was thinking of some sort of staging branch, but I can't think
of a good way to make it work.  The crux of the issue seems to be that
a developer needs to somehow give a version control promise that they
will do the merge, even if the merge isn't done yet, because otherwise
anyone else coming afterwards will duplicate the work (potentially
incorrectly).  That would mean some kind of lock though, which sounds
like a terrible idea...

-tom

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

Re: [Mesa3d-dev] mesa_7_7_branch -> master merges

[Keith Whitwell]

On Mon, 2010-01-25 at 11:04 -0800, tom fogal wrote:
> I think we've touched on a core git workflow issue here, and its likely
> others have hit this && have a solution, so I've added the git ML to
> the CC list.
> 
> Git: the situation in this repo is a fast-moving master that is
> including many changes to internal interfaces.  Stable branches just
> get bugfixes, and are periodically merged to master.  However, the more
> the heads diverge, the more difficult it is for a bugfix to merge into
> the head.  The major issue is that more experienced developers should
> really weigh in on these merges, because they tend to automagically
> undo some of the interface changes.  Yet during such a delay, master
> inevitably moves, and the bugfixer has to do even more work to "redo"
> the merge (and potentially get more review!).
> 
> Of course, if there are two bugfixers trying to make separate changes
> in the same time period, this gets worse.
> 
> Is there a workflow that can solve this issue?
> 

Speaking from the Mesa side, I think part of our problem is that it's
not easy to build the entire mesa tree, which means that the developer
doing the merge cannot even compile-test the result, meaning that many
trivial failures go unnoticed.

I'd argue that if we had a maximal mesa build target that compiled
*everything*, regardless of whether it produced drivers or not, we'd
have a much better chance of catching bogus merge droppings.

Despite Jose's valid concerns, I'd still argue that the situation we
have now is superior to what came before - where people were supposed to
be cherry-picking bugfixes but more likely they were forgotten or it
fell on Brian's shoulders to do manually.

Keith