Re: Display outstanding backported fixes for each release?

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
Received on 2019-01-03 16:59:04 CET