Re: Avoiding slowdown in trunk development

[Lennart Borgman <lennart.borgman@gmail.com>]

On Tue, Feb 1, 2011 at 8:04 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
>
> But that's not the case here.  The special needs of the Windows port
> are not a good reason to slow down mainline development.

Every platform has it special needs. There is no running Emacs without
platform dependent parts.


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

After reading this I am quite sure we need a policy for changes that
are known to break some commonly used platform. My suggestion is
(again) using a separate branch.

I can't see any solid reason in your arguments not to have a separate
branch for such changes. Maybe I am wrong.

You have said that it takes you extra time to have such a branch and
also that it takes a lot of time to do the merges. I have a hard time
to understand that so I ask you:

- What are the cost of an extra branch? Is there something that could
make this cost less?

- Why do you think that the merge will be difficult? I expect it to be
rather few changes at the locations where you are changing things. Is
not that your expectation too?

I got a lot of patches and some of them are unfortunately in parts
where things are changed and that causes me a lot of trouble
sometimes. However that trouble is less if I am able to merge more
often. With your suggestions I would be able to merge and build less
often so your suggestions would really cause at least me trouble.