[Top][All Lists]

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

Re: Emacs contributions, C and Lisp

From: Phillip Lord
Subject: Re: Emacs contributions, C and Lisp
Date: Thu, 27 Mar 2014 17:08:14 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eli Zaretskii <address@hidden> writes:
>> Something like the gitorious merge request facilities would help here.
>> Then you would be able to see that your request had gone in. Mailing
>> lists are good for some things but maintaining a database is probably
>> not one of them.
> What we really need is to have in place an efficient and effective
> procedures for patch review and application.  Without that, patches
> will collect dust on gitorious as they will in the archives of this or
> another mailing list.

Yep, but the flip side is that it is easier to see which patches are
gathering dust. That's always a good motivator. I mean, it's like a todo
list; yes, you still have to do the things on the todo list, and if you
don't it comes big and pointless. But, I have found my todo handling is
a little more efficient since I discovered org-mode to replace either
post-it notes or my (every failing) memory.

> So I think you are putting the carriage ahead of the horse.  We need
> first to have "patch pilots" and maybe some support rules, and then
> those people will pick up the tools they like best for doing their
> job.  Having a database of patches that no one looks upon will lead us
> nowhere.

Again, I think this is partly true, but my experience is that it's
easier to pull a branch and switch to it, than it is to handle patches.

Processes are important. But so are tools. It's why I use Emacs rather
than ed for instance.


reply via email to

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