[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
True.
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
schedule.
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.
--
Bastien
- Re: Next pretest, and regressions policy, (continued)
- Re: Next pretest, and regressions policy, Bastien, 2012/04/01
- patch vs. overwrite in bzr [was: Next pretest, and regressions policy], Roland Winkler, 2012/04/03
- Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy], Óscar Fuentes, 2012/04/03
- Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy], Bastien, 2012/04/03
- Re: patch vs. overwrite in bzr, =?utf-8?Q?=C3=93scar_Fuentes?=, 2012/04/03
- Re: patch vs. overwrite in bzr, David Engster, 2012/04/03
- Re: patch vs. overwrite in bzr, Stefan Monnier, 2012/04/03
- Re: patch vs. overwrite in bzr, Michael Albinus, 2012/04/03
- Re: patch vs. overwrite in bzr [was: Next pretest, and regressions policy], Stefan Monnier, 2012/04/03
- Re: patch vs. overwrite in bzr, Glenn Morris, 2012/04/03
- Re: patch vs. overwrite in bzr,
Bastien <=
- Re: patch vs. overwrite in bzr, Glenn Morris, 2012/04/03
- Re: patch vs. overwrite in bzr, Stefan Monnier, 2012/04/03
- Re: patch vs. overwrite in bzr, Bastien, 2012/04/04
- Re: patch vs. overwrite in bzr, Bastien, 2012/04/04
- Re: patch vs. overwrite in bzr, Michael Albinus, 2012/04/04
- Re: patch vs. overwrite in bzr, Thierry Volpiatto, 2012/04/04
- Re: patch vs. overwrite in bzr, Stefan Monnier, 2012/04/04
- Re: patch vs. overwrite in bzr, Jordi Gutiérrez Hermoso, 2012/04/04
- Re: patch vs. overwrite in bzr, Paul Eggert, 2012/04/04
- Re: patch vs. overwrite in bzr, Eli Zaretskii, 2012/04/04