Re: Avoiding slowdown in trunk development

[Paul Eggert]

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.  I often do
this sort of thing, but it consumes valuable think time and
context-switching time (i.e., the context inside my head :-) to
maintain a separate line of development.  It's more efficient to avoid
that when possible, as is the case here.

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

> There are many other projects with more
> disciplined commit policies, where e.g. a commit requires an a-priori
> approval; surely it doesn't mean those projects are unduly slowing
> down their development?

There are many reasons why projects might need a change control board
or similar mechanism.  Such mechanisms almost invariably slow down
development.  If they're needed anyway, despite that disadvantage,
then they are slowing down development for good reason.

But that's not the case here.  The special needs of the Windows port
are not a good reason to slow down mainline development.

>> > if that commit fails due to a nearly-simultaneous
>> > trunk commit by someone else, I typically just revert my copy of the
>> > trunk and start over.
> 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.

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.

>> > The Windows port should not require mainline developers
>> > to spend significant chunks of their time.
> How is this different from spending time on fixing problems of other
> proprietary platforms, e.g. Solaris?

It is greatly different as a practical matter.  Solaris is quite easy
to port to, and mainline development is not significantly
impeded by concerns about a Solaris port.  In contrast,
Windows is not nearly as easy to port to, and concerns about the
Windows port are getting in the way of mainline development.

> Please also note that in Emacs, most of the development happens in
> platform-independent and device-independent parts, so people who track
> the development trunk are not used to breakage that affects a single
> platform.

In that case, perhaps all that's needed is a minor adjustment in
expectations.  When Emacs's platform-independent parts are being
changed, Windows developers can continue to expect Emacs to build.
When the platform-dependent parts change, they can expect builds to
fail temporarily, until someone who's versed in Windows adjusts the
Windows build procedure.  This approach is quite common in other
projects, and it works for Emacs as well.