[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: patch vs. overwrite in bzr

From: Bastien
Subject: Re: patch vs. overwrite in bzr
Date: Tue, 03 Apr 2012 22:50:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.94 (gnu/linux)

Glenn Morris <address@hidden> writes:

> Stefan Monnier wrote:
>> Remember somewhere which was the last revision of Org that was sync'd to
>> Emacs, and then create the patch by diffing against that revision.
> As was said last time this happened (which is basically every time):
> http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00648.html


I already complained about two things: the lack of mechanism to
systematically send commits about a module (org/gnus/tramp) to the
maintainer of this module; the lack of visibility for the release

Both problems create additional work.

The first one because I need to watch the emacs-diffs mailing list
carefully and backport small commits to Org (80% of the last 67 commits
in the last 480 days were just useful but trivial commits).  To improve
the situation we could have 3-4 Emacs hackers directly committing in Org
while the maintainer focuses on syncing regularily.

The second one because it forces us to maintain a separate branch in
Org's repo, the one that corresponds to the current Emacs trunk.  I
already suggested a possible improvement (not a solution) about this:
have a different feature freeze window for modules and for Emacs core,
but got 0 answer.

Now that I'm thru with complaining, I 100% acknowledge my laziness in
setting up a good process for the 2-way sync.  But I will.  I'll see if
it works over time.

Finally, I'm curious to know whether you, Juanma and Paul would be
willing to commit fixes directly in the "hotfix" branch of Org's git.
This is the branch that is sync'ed with Emacs trunk, and committing
small fixes there first would remove 90% of the pain.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]