Re: patch vs. overwrite in bzr

[Thierry Volpiatto <thierry.volpiatto@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>> Date: Wed, 04 Apr 2012 10:35:34 +0200
>> 
>> I never understood why Emacs have not a developing branch to continue
>> developing new features during the feature freeze.
>
> Read the archives for past discussions of this issue, and you will
> understand.  The reason is insufficient resources.  It takes a
> significant effort to run a pretest, triage the bugs and fix important
> ones, update the manuals, etc.  The extremely small number of core
> maintainers does not leave resources to overview both the branch and
> the trunk, as long as there's lots of work on each one of them.
You should not have to overview the dev branch, only the trunk and merge
regularly it in the dev branch. You would have only to review the
patches before applying to dev branch, but that's what you already do I
think. The difference is just that actually you say, yes patch is ok we
will apply it after feature freeze. Instead you would just have to apply 
if ok.


> People who want this to change should volunteer to do the tasks that
> are needed to be done for the pretest and release.  Then 2 things will
> happen: (1) there will be more people who can take a responsibility
> for a release, thus freeing more time for the head maintainers to take
> care of the trunk; and (2) the number of people who are familiar with
> Emacs enough to become core maintainers will also grow.
>
>> I think Emacs lost a lot a new features during this process, especially
>> from contributors that send patches; most patches are lost or
>> are unusable after several months of modifications in trunk.
>
> If you use bzr or any other dVCS, you can simply put your changes on a
> branch or even a shelf, and then when the time comes to push them, you
> will have much less trouble than you think.  Modern VCSes do a very
> good job at merging.
I know this, I use patches that I can pop and push again after pulling
last changes upstream.


-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997