|
From: | David Chisnall |
Subject: | Re: Next GNUstep release |
Date: | Mon, 6 Apr 2020 09:53:00 +0100 |
User-agent: | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
ChangeLog files made sense when people were submitting patches on the mailing list and distributing code in tarballs.
They were slightly anachronistic when CVS became standard for F/OSS projects and incorporated per-file change messages but they were still useful when people used them to describe the relationship between changes in multiple files.
They were mostly obsolete when projects moved to svn and commits became atomic. Commit messages then referred to a set of related changes, rather than to single files. The one remaining argument for them was that VCS history may get lost in moves between revision control systems.
There was also a minor justification for them based on tooling: commit messages for svn were written after code review and some tools did not support reviewing the commit message along with the code (things like Phabricator did), so you could enforce a ChangeLog message in code review but you could not enforce a commit message at the same time.
We have now seen projects move from CVS to SVN and then to Git, preserving commit messages. Git commits have evolved a structure that is well supported by a load of tooling (vim even gives nice syntax highlighting to ensure that you confirm to this structure, all of the Git GUIs, including GitHub, are designed to render it), where the first line is short and gives a very high-level summary of the changes and the remainder gives a detailed overview. No equivalent tooling exists for ChangeLog files.
In addition, a branch-and-PR workflow makes it possible to do code review of commit messages before merging. Git makes it easy to edit and amend commit messages and force-push a branch, so individual commits can have their messages edited before a branch is merged.
I would much rather see code review enforcing good commit messages, which is a workflow that contributors to any other open source project will be familiar with. I fail to see any benefit in having ChangeLog entries.
Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file that captures high-level user-visible improvements. We don't necessarily need PR authors to write that, but the person merging a PR probably should if not. This is far less granular than a commit message and serves a separate purpose.
David On 05/04/2020 21:49, Fred Kiefer wrote:
Thank you Ivan for the great work you are doing here. And I promise to try to lighten the work on the next release by making sure every pull request gets it proper ChangeLog entry. FredAm 05.04.2020 um 22:42 schrieb Ivan Vučica <address@hidden>: I have cut new releases: - gnustep-make 2.8.0 - gnustep-base 1.27.0 - gnustep-gui 0.28.0 - gnustep-back 0.28.0 They've been pushed to GitHub as commits and signed-tags, signed using GPG key of yours truly. The signed tags, interpreted as releases by GitHub, have been marked as 'prerelease', and tarballs + GPG signatures made using the maintainer key have been attached to them. https://github.com/gnustep/tools-make/releases/make-2_8_0 https://github.com/gnustep/libs-base/releases/base-1_27_0 https://github.com/gnustep/libs-gui/releases/gui-0_28_0 https://github.com/gnustep/libs-back/releases/back-0_28_0 As a temporary download URL, they're also available at https://badc0de.net/gs/2020/ for anyone who does not use GitHub. Please, have a go at them, and let me know if there are any critical issues. Please particularly review ANNOUNCE files as these will customarily go out to address@hidden. ANNOUNCE files should be the same ones that have been committed into our Git repositories. Please validate .sig files in case I made a mistake; that would be rather embarrassing. If there are none, one of the evenings next week I will: - upload tarballs to the default distribution point at ftp.gnustep.org - flip the 'prerelease' bit on GitHub - send ANNOUNCE emails to address@hidden and to address@hidden as was done for previous releases. Thank you everyone for your work! While preparing these was a lot of work, I am also impressed by the amount of changes all across the board: tons of new classes, tons of work on Android; very very impressive amount of changes.
[Prev in Thread] | Current Thread | [Next in Thread] |