On Thu, Jan 3, 2019 at 10:58 AM Julian Foad <julianfoad_at_apache.org> wrote:
> 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.
>
If we did not keep the STATUS file in the branch, then wouldn't it be
fairly easy for anyone to see the info you want just by using svn log? It
seems like the only barrier to that today is all of the "noise" generated
in the branch via the STATUS file activity.
> 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.
>
Of course. I was not suggesting the process be manual. I was saying I had
no idea what you were proposing so maybe it makes sense to manually
generate some examples before discussing how to script it. It is kind of
hard to have an automation discussion when it is not at all clear what you
want to automate.
Even with your svn log examples, there is still the issue of how you would
want to display that info on the ROADMAP page. If the output from log is
not suitable for display then we would still need to see what a suitable
display would look like so that we could discuss how a script might massage
the log output into the desired format.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2019-01-03 17:25:27 CET