On 30 Jul 2012, Óscar Fuentes spake thusly:

> Eli Zaretskii <eliz@gnu....> writes:
>> The real price to pay will be the bugs we miss on each separate
>> platform, which are only revealed on the other, due to a different
>> compiler/library/environment/memory arrangement/whatever.  How many
>> times in the past bugs in the Emacs code were found on Windows (or
>> even in the MS-DOS port)?  Segregate the ports, and you will lose all
>> that.  In effect, the project will be split into several ones that
>> hardly ever communicate.
>
> I don't see how using a branch instead of #ifdef's with its associated
> platform-specific macro definitions makes any difference here.

Well, you can if you like think of a branch as being equivalent to a
giant #ifdef around every single file, splitting each file into sections
as large as the whole file is now, one for each platform.

And that is where the problem lies. Right now, most of the code in Emacs
is generic, and people who encounter bugs (or mistaken portability
assumptions) in that code on one platform, and fix it, fix it on all.
With multiple per-platform branches, that doesn't happen. (Particularly
with bzr as bad as it is at keeping branches in synch. Cross-branch
merges? Really?)

Splitting ports into their own branches might be done because the port
maintainer just can't get on with the other maintainers, or because
their port is churning hard in early bringup phase and they're planning
to merge back to trunk when it settles down, but I can't see a
*sensible* reason to do it long-term.

--
NULL && (void)