From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Is it time to drop ChangeLogs? Date: Fri, 08 Jul 2016 09:27:55 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87lh1cb6p0.fsf@lifelogs.com> References: <56BE7E37.3090708@cs.ucla.edu> <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <87twg2g86g.fsf@lifelogs.com> <83eg76n5h5.fsf@gnu.org> <87y45eeoor.fsf@lifelogs.com> <577D42BB.1020500@cs.ucla.edu> <87oa694rfw.fsf@russet.org.uk> <837fcxlbay.fsf@gnu.org> <87lh1d2wg5.fsf@russet.org.uk> <83eg75jk5h.fsf@gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1467984559 25685 80.91.229.3 (8 Jul 2016 13:29:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Jul 2016 13:29:19 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 08 15:29:12 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 1bLVq6-00032K-Vo for ged-emacs-devel@m.gmane.org; Fri, 08 Jul 2016 15:29:07 +0200 Original-Received: from localhost ([::1]:45637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLVq5-0007qo-Nl for ged-emacs-devel@m.gmane.org; Fri, 08 Jul 2016 09:29:05 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLVpG-0007ot-Ly for emacs-devel@gnu.org; Fri, 08 Jul 2016 09:28:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bLVpC-0005St-HF for emacs-devel@gnu.org; Fri, 08 Jul 2016 09:28:13 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:59987) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bLVpC-0005Si-9I for emacs-devel@gnu.org; Fri, 08 Jul 2016 09:28:10 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bLVp9-0002Qp-Hj for emacs-devel@gnu.org; Fri, 08 Jul 2016 15:28:07 +0200 Original-Received: from c-98-229-60-157.hsd1.ma.comcast.net ([98.229.60.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jul 2016 15:28:07 +0200 Original-Received: from tzz by c-98-229-60-157.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jul 2016 15:28:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 82 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-60-157.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:VbCKV5ztZORAKz6wD53jGVFmfoY= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:205425 Archived-At: On Thu, 07 Jul 2016 22:57:46 +0300 Eli Zaretskii wrote: EZ> Problem is, I don't find the subtle fine points that need addressing EZ> until I actually apply the patch: compiler warnings, code not EZ> according to our conventions, sometimes patch won't apply, etc. Typically this is addressed with a build system that takes every pull request and builds it, logging problems right into the pull request. EZ> All the other projects I EZ> participate in make it harder, and yet no one complains or thinks they EZ> are hard on contributors. I think there is a confirmation bias there: people tend to believe the feedback that confirms their existing views and discount the opposite. On Fri, 08 Jul 2016 12:28:32 +0100 phillip.lord@russet.org.uk (Phillip Lord) wrote: PL> I think that the discussion is bottoming out here. If there is interest, PL> I will be happy to investigate some of the options and produce a report PL> of pros and cons. Alternatively, if the general feeling is, it's all PL> fine, then no worries, I'll leave it. On Fri, 8 Jul 2016 02:50:31 +0300 Dmitry Gutov wrote: DG> That said, before continuing this discussion, I'd rather we switch to a DG> modern-ish bug tracker first. As I said, I'll try using the (painful) bug tracker to do code reviews. Please consider me strongly in favor of a better code review system and a better bug tracker. Ideally they would be one and the same. On Thu, 07 Jul 2016 17:56:01 -0400 Richard Stallman wrote: RS> Are you saying that most projects do not keep track of which functions RS> are changed in each commit? RS> How can maintainers figure out how to solve problems without detailed RS> log records to show them which previous changes they need to study? The code review (pull request handling) system has all that information. For instance, you can search for error messages, not just the commits that fixed them. The real value emerges when the entire development workflow is captured in the same place, indexed for searching, and open for world-wide review and contribution. >> The pull request system can later provide *everything* that a >> ChangeLog could, RS> I am skeptical of this claim. How precisely will the pull request system RS> provide what we now get from the detailed lists of objects changed RS> in the log entries? The ChangeLog structure is something like this: top-level-message file1: message1 symbol1: message11 symbol2: message12 file2: message2 ... This can easily be encoded in a database table so it's searchable, indexed by symbol name or file name (to build a history), etc. as part of the pull request system. It can be semi-automatic: the system figures out the file and symbol changes, then the developer adds the rest (and the review doesn't end until this is done). The database can be part of the Emacs Git repository, it doesn't have to be something magical outside it. But that's an architectural decision. The end result is a lot like the ChangeLog format we have today... except it's structured data, linked to a *series* of commits *and* the code review on them. That piece doesn't exist, but I'm willing to bet that developing it is *much less* work than the man-hours that will be spent crafting the ChangeLog format over the coming years. Consider as well that it will be useful to the whole GNU project, not just Emacs. Ted