[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Avoiding slowdown in trunk development
From: |
Lennart Borgman |
Subject: |
Re: Avoiding slowdown in trunk development |
Date: |
Tue, 1 Feb 2011 20:54:17 +0100 |
On Tue, Feb 1, 2011 at 8:04 PM, Paul Eggert <address@hidden> 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.