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 19:53:53 +0200
>> 
>> 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.
>
> Not true.  There's a difference between doing a triage and actually
> considering the patch for inclusion.  In addition, "overviewing" means
> discussing design and implementation for significant contributions.
> Development is not just patch reviews, at least not in Emacs.
You are already doing this, so it is not extra work.

>> >> 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.
>
> Then why do you present patch-rot as a significant factor?
Most people don't want to do this and just do not contribute, so you
lose many potentials contributors.

> It isn't.
It is actually not easy to contribute to Emacs.

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