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: Thu, 07 Jul 2016 09:18:51 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <871t35egck.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> <8337nmn2pd.fsf@gnu.org> <87shvmem2c.fsf@lifelogs.com> <87oa6adz3w.fsf@lifelogs.com> <577E056B.1060705@cs.ucla.edu> 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 1467897703 17953 80.91.229.3 (7 Jul 2016 13:21:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2016 13:21:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 07 15:21:34 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 1bL9F5-0004Tb-Io for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 15:21:24 +0200 Original-Received: from localhost ([::1]:39920 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL9F4-0005cn-PP for ged-emacs-devel@m.gmane.org; Thu, 07 Jul 2016 09:21:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL9D5-0003Mm-P7 for emacs-devel@gnu.org; Thu, 07 Jul 2016 09:19:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bL9D0-00044w-HM for emacs-devel@gnu.org; Thu, 07 Jul 2016 09:19:18 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:51271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bL9D0-00044p-6W for emacs-devel@gnu.org; Thu, 07 Jul 2016 09:19:14 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bL9Cv-0002wl-TB for emacs-devel@gnu.org; Thu, 07 Jul 2016 15:19:10 +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 ; Thu, 07 Jul 2016 15:19:09 +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 ; Thu, 07 Jul 2016 15:19:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 111 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:PdKx6Y368FHHQ+PyyTMnnlHvWmo= 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:205319 Archived-At: On Thu, 7 Jul 2016 09:31:55 +0200 Paul Eggert wrote: PE> On 07/07/2016 04:44 AM, John Wiegley wrote: >>> I disagree with this. Processes such as the one here are learned behavior, >>> >not something that identifies good vs. bad programmers. >> You are right, of course, Ted PE> Yes and no. Good software engineers are adept at software processes, and this is PE> mainly what distinguishes them from mere good programmers. If we want PE> high-quality software then we need software engineering, not mere PE> programming. You're right, Paul. My point, however, is that writing ChangeLog-style commits is definitely not something you'll learn in school or in industry, and we shouldn't turn it into a shibboleth by itself. Working with GNU software is fun, but it's a tiny community compared to the world-wide developer community. It's hard to grow it if contributors are judged on the ChangeLog-style formatting on their first contributions. On Thu, 07 Jul 2016 12:29:23 +0100 phillip.lord@russet.org.uk (Phillip Lord) wrote: PL> Where PRs work better over direct commits is when ever someone wants PL> comments and feedback. There are two main reasons for this. One is where PL> commits need to be checked by someone else before going in; the emacs-25 PL> branch is in this state at the moment. PL> The other is where someone wants feedback on their work, because they PL> are new, or because they are fiddling with parts of Emacs which they PL> understand poorly. Exactly! What I'm suggesting would benefit those two cases the most. PL> Installing something like gerrit or kallithea would be nice (I have no PL> direct experience of using either, but they are similar to other PL> systems). However, this would be considerable work. PL> Perhaps, as a half way house, we could use the resources that we have. PL> PRs could go to the bug reporting system. This will, at least, keep all PL> the conversations in one place. If we can tag these with "has patch" PL> here as well, it will give an queue also. We would still need to do PL> something about the Emacs git, in terms of squashability; in practice, PL> this would probably require something like gitolite as allowing non-FF PL> pushes on all branches would be a bad thing. PL> This would not give a nice web interface, nor inline comments, but it's PL> a start. So maybe the workflow can be: 1) propose a patch on emacs-bug with tag `has patch'. A Git branch pointer is also acceptable? 2) a reviewer comments; patch/branch is reworked 3) reviewer signs off and commits patch / merges branch This is similar to how the Git project does it. It can be a bit chaotic, but seems to work for their scale (which is similar to Emacs' scale). It won't require new software. As Noah mentioned, we already have (1) with http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;include=tags%3Apatch;bug-rev=on but (2) and (3) are not "expected" or in any way documented. So the contributor docs would be adjusted to mention these steps. That's a pretty small amount of voluntary effort, and no one has to follow these steps that doesn't want to. I sincerely hate the current bug tracker, but am willing to work with it if that's what it takes to get this moving. As a first attempt, I'll post my gnus-cloud work when it's ready for review. On Thu, 7 Jul 2016 08:43:30 -0400 Noam Postavsky wrote: NP> So maybe we just need some more support in vc-git to make sending NP> patches less clunky? I've been sending patches to bug threads, and NP> often getting useful feedback on them (and since it's by email, the NP> comments can easily be inline). Personally, I don't find it more NP> clunky than pushing to a branch, and then opening a PR in a web NP> browser. For a single patch, e-mail works. For multiple commits, rebasing, adjusting, it can be overwhelming. NP> Yes, some patches are forgotten, but I don't see how a PR NP> "system" makes that less likely to happen, e.g., cask has a bunch of NP> open PRs sitting around: https://github.com/cask/cask/pulls. A PR system makes it easier to find forgotten submissions. Usually it can assign a reviewer, who then should get regular reminders. But, of course, it won't fix lack of manpower or lack of interest. It's just a virtual clerk. On Thu, 7 Jul 2016 12:46:07 +0000 Alan Mackenzie wrote: AM> I don't know exactly what is meant by "pull request" and "pull request AM> system". I don't think they are established terms. AM> The term seems to imply that instead of a contributor pushing a change AM> from his machine to a central repository, some specially authorised AM> authority would pull the change from the contributor's machine. This AM> would seem to imply every contributor needing to set up an scp daemon on AM> his local machine, which doesn't feel like a Good Thing. They are well known today, and have existed (in the form of patch reviews) for a long time. Wikipedia doesn't have much, but https://help.github.com/articles/using-pull-requests/ has a pretty good overview. It shows the Github UI, but the steps are the same without it. The Git book has some good workflow suggestions as well https://git-scm.com/book/ch5-2.html Ted