Re: Avoiding slowdown in trunk development

[Eli Zaretskii]

> Date: Tue, 01 Feb 2011 11:04:44 -0800
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> On 02/01/11 00:58, Eli Zaretskii wrote:
> 
> > A couple of possible workflows come to mind:
> 
> Both of those suggestions would take more developer time.  For example,
> I might have to figure out which changes to cherry-pick from other
> codelines and would have to deal with merge conflicts.

That'd be rare, I imagine.  It is for me, when I withhold a changeset
for some reason or another.  Maybe you are talking from experience in
another project, which is not necessarily applicable to Emacs
development.

> It's more efficient to avoid that when possible, as is the case
> here.

Yes, but at what price?  Breaking the build for several people is a
heavy price in my book.

> > But I don't see how a couple of days of delay could possibly be of any
> > practical importance; do you?
> 
> Sure they can.  Either they slow down that line of development a
> couple of days, which is bad in real-time, or they require more
> context-switching and merging, which is bad in developer-time.

I asked about practical importance, not theoretical one.  Some amount
of friction is inevitable in a project developed simultaneously by
several people.  We cannot behave as if each one of us owns the
project, and to heck with others.

> > I hope by "revert" you meant "bzr up", not "bzr revert".  The short
> > time window for the kind of race condition that could happen in this
> > situation will rarely cause changes in parts that are related to your
> > changes.
> 
> Near-simultaneous changes have caused problems for me.
> bzr may be good at merging, but its errors are common enough to be of
> concern to me.  So I take a more cautious approach using "bzr revert".
> This approach has not caused problems.

But it slows you down and makes your work less efficient.  And that
affects others, because you are unwilling to modify your workflow on
behalf of merge problems which I personally saw maybe once, if at all.

> At any rate, I don't see how that caution is relevant.  No matter
> which bzr style one uses to merge changes, the main problem is
> the hassle of merging, not the bzr style one uses to merge.

There's no hassle, in my experience.  It "just works".

> In that case, perhaps all that's needed is a minor adjustment in
> expectations.

I can hardly imagine this is going to happen.