From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is it time to drop ChangeLogs? Date: Wed, 09 Mar 2016 22:30:41 +0200 Message-ID: <837fhbo0lq.fsf@gnu.org> References: <56BE7E37.3090708@cs.ucla.edu> <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <64a52598-ad53-498c-993c-67d7827dbdfc@default> <838u1uuuau.fsf@gnu.org> <878u1um2xl.fsf@thinkpad.rath.org> <87fuw090k7.fsf@wanadoo.es> <83y49spuxt.fsf@gnu.org> <87pov4achc.fsf@acer.localhost.com> <83r3fkpb3u.fsf@gnu.org> <87oaanctvw.fsf@acer.localhost.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1457555469 8176 80.91.229.3 (9 Mar 2016 20:31:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2016 20:31:09 +0000 (UTC) Cc: ofv@wanadoo.es, emacs-devel@gnu.org To: Ingo Lohmar Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 09 21:30:56 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1adkkx-0003lM-K0 for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 21:30:55 +0100 Original-Received: from localhost ([::1]:44157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adkkt-0001iG-OZ for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 15:30:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adkkc-0001i6-PI for emacs-devel@gnu.org; Wed, 09 Mar 2016 15:30:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adkkY-000470-Fz for emacs-devel@gnu.org; Wed, 09 Mar 2016 15:30:34 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adkkY-00046w-61; Wed, 09 Mar 2016 15:30:30 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4264 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1adkkX-0003OY-EK; Wed, 09 Mar 2016 15:30:29 -0500 In-reply-to: <87oaanctvw.fsf@acer.localhost.com> (message from Ingo Lohmar on Wed, 09 Mar 2016 20:51:15 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201316 Archived-At: > From: Ingo Lohmar > Cc: ofv@wanadoo.es, emacs-devel@gnu.org > Date: Wed, 09 Mar 2016 20:51:15 +0100 > > > Emacs development doesn't work by requiring each commit be posted for > > review as prerequisite for committing, so what Oscar suggests is not > > possible. (Please don't ask why, it was explained many times > > already.) > > Do you mean in this thread or elsewhere? Both. (This is not the first time these issues are discussed.) > I would honestly appreciate it if you could point me to such a > discussion, as I am not aware of the arguments. In one word: manpower. In 3 words: lack of manpower. > In fact, in this very thread, the previous Emacs maintainer > has contemplated an automatic queueing system, so it surprises me that > such a scheme should be totally out of the question. It's not out of the question. But we are just contemplating it. Before we could rely on it enough to make significant decisions like the one discussed here, we'd need stop contemplating, install the procedures to implement such a queuing system, run it for a while, perhaps augment it some, until it's reliable enough and brings consistently good results. _Then_, and no earlier, we can base changes in development process on such a system. We are not there yet. Until we are, we need to find a workable solution with what we have now. > > Find a better and more reliable way of dealing with the problems > > described here, and I'll be the first to agree not to reintroduce > > ChangeLogs. > > Several solutions to both a) and b) were proposed in this thread. Unfortunately, they don't fit the bill. See the rest of the thread for why.