Re: Merging Org 7.8.02 before Emacs 24.1

[Bastien]

Chong Yidong <address@hidden> writes:

> Bastien <address@hidden> writes:
>
>> IMHO the feature freeze would make more sense if there was a deadline
>> for the Emacs release.  Is there one?
>
> There is no deadline.  It will take at least a few more months, but we
> are close enough that a further Org merge after this one will most
> likely be unacceptable, unless it is purely bug fixes.

I'll leave it to you and the Emacs team to judge whether those new
features are acceptable or not during the feature freeze.  I guess it
all depends on the features themselves (probably small ones for 7.9) 
and the deadline.

> If you guys are continuing to add features upstream, I recommend setting
> up a bugfix-only branch or some other setup for channeling upstream bug
> fixes into the Emacs trunk, for the duration of the Emacs pretest.

This is what I will try to do from now on: the Org master branch is for
development and the maint branch is for bug fixes.

But there is a problem: each time there is a new Org major release, the
master branch is merged on the maint branch.  If new bug fixes are done
after the major release, how should I merge them into Emacs?

I can think of two solutions: (1) have an emacs-maint branch containing
bug fixes for the last Org version that has been merged into Emacs; the
master branch will be merged on that branch only when the major release
of Org is merged into Emacs; (2) don't merge bug fixes that happen after
a new major release during the feature freeze.

Unless someone come up with a better (simpler) proposal, I will perhaps
try (1) -- if that's too much work, I will fall back on (2).

Best,

-- 
 Bastien