The itch I'm scratching is this: I want the people who are interested in our
patch releases, and who read our CHANGES file, to be able to see what changes
are coming or likely to be coming in the next patch release.
As an example, a few weeks ago a downstream packager/distributor asked me, "are
there any server-side fixes coming in the next 1.10.x patch release?" I was
disappointed to realize that there wasn't a quick self-serve answer to that.
There are several possible solutions. All that matters to me is that end-users
can easily find the information. It would be ideal in the form that we use for
CHANGES file entries, but it doesn't have to be as "digested" as that.
Mark Phippard commented:
> Seeing the commits is too low level to be useful on the website...
That is true for trunk changes: there, every meaningful change is built from a
series of commits, many of which are trivial or meaningless in isolation, and
rarely is there a single commit that describes the whole change well. However,
a backport branch is very different: there, every backport commit should be a
complete, meaningful, tested, documented, change. So showing commits (even a
raw log output) is meaningful.
Given that we don't yet keep CHANGES up to date, I am thinking a reasonable
short-term solution could look like this (example for the 1.9.x branch):
$ svn log -r1:HEAD --limit=1 --stop-on-copy ^/subversion/tags/1.9.9 -vq
------------------------------------------------------------------------
r1835933 | julianfoad | 2018-07-14 21:43:40 +0100 (Sat, 14 Jul 2018)
Changed paths:
A /subversion/tags/1.9.9 (from /subversion/branches/1.9.x:1835931)
M /subversion/tags/1.9.9/subversion/include/svn_version.h
------------------------------------------------------------------------
# note the parent branch copy-from revision -- 1835931 -- and add one
$ svn log -r1835932:HEAD ^/subversion/branches/1.9.x > commits-on-1.9.x
$ vim commits-on-1.9.x
# filter out all the log entries that are not merges (manually, this time)
Result:
[[[
------------------------------------------------------------------------
r1837042 | julianfoad | 2018-07-30 11:35:08 +0100 (Mon, 30 Jul 2018) | 10 lines
On the '1.9.x' branch: Fix german translation for 'svn help merge'.
(Merge r1837037 from trunk.)
Patch by: Christoph Vogtländer
<Christoph.Vogtlaender{_AT_}sigma-surface-science.com>
* subversion/subversion/po/de.po
Fix translation error and a typo in help text regarding the reintegration
of a feature branch back to trunk.
------------------------------------------------------------------------
r1845529 | svn-role | 2018-11-02 04:00:05 +0000 (Fri, 02 Nov 2018) | 9 lines
Merge r1844882 from trunk:
* r1844882
Fix propagation of mod_dav_svn's SVNUseUTF8 configuration setting.
Justification:
The option has no effect in some setups. User submitted the patch.
Votes:
+1: stsp, brane, rhuijben
------------------------------------------------------------------------
[...]
------------------------------------------------------------------------
r1849263 | svn-role | 2018-12-19 04:00:33 +0000 (Wed, 19 Dec 2018) | 13 lines
Merge the 1.9.x-issue4791 branch:
* r1847572, r1847596
fsfs: Fix SVN-4791, an issue with the DAG open_path() that was causing
unexpected SVN_ERR_FS_NOT_DIRECTORY errors when attempting to open a path
with `open_path_node_only | open_path_allow_null` flags.
Justification:
Some valid FSFS read operations errored out. This could break some
end-user operations like 'update'.
Branch: 1.9.x-issue4791
Votes:
+1: julianfoad, brane, stefan2
------------------------------------------------------------------------
]]]
This output contains roughly the same level of information as if we had filled
in the CHANGES file. Of course it's not the same, but for these purposes it's
enough to start with.
To that list of merged backports I would want to add the lists of proposed
backports. We can do this by literally appending a copy of the STATUS file.
Again, if we had prepared CHANGES entries in advance, that would surely be
nicer, but it's enough to start with.
Where and how to display the information? Our roadmap page would be an obvious
place to look for it. So, I envision a section there called something catchy
like "Upcoming changes in the next patch release in each supported release
line". Under that heading, either inline or links to the verbose text samples
above.
I will reiterate: I would not propose to do this at all if it has to be
manually updated, only if we can auto-generate it.
- Julian
