Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 02 Aug 2012 08:12:29 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> Cc: emacs-devel@gnu.org
> 
> On 08/02/2012 03:52 AM, Stefan Monnier wrote:
> 
> > Then, please undo your changes.  The INTERNAL_FIELD part is fine, but
> > the new FVAR, WVAR, ... are not.  Maybe it can be useful as an
> > intermediate step on some separate generational-gc branch, but it
> > doesn't have its place in trunk:
> 
> Look at concurrency branch. Everyone agrees that this is an interesting
> and useful feature, but no one wants to handle an endless merging efforts.

I cannot speak for Tom and the concurrency branch, but in my
experience the merging is almost a non-issue.

> Again, this is a kind of chicken-egg problem: it's very hard to design
> GC bits without supporting infrastructure implemented, and no one wants
> to deal with obfuscated internal things in the absence of visible
> advantages provided by new GC. IMHO the only solution is to suffer
> some obfuscation until it becomes really useful.

In general, at least in this project, if a feature needs to be
developed incrementally over a significant time period, then it is
better to do it on a branch, and then merge it onto the trunk when it
is more or less ready and stable.  Experience taught me that this
paradigm minimizes friction with people who just want to track the
latest code, but not be alpha-testers for unstable new features in the
core that cannot be easily turned off.