Re: Next GNUstep release

[David Chisnall]

I second that, thank you Ivan, but Fred your proposed solution is going 
to add more barriers to entry.

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.
>
> Fred
>
> > Am 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.