You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@apache.org> on 2019/01/03 15:58:55 UTC
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
Re: Display outstanding backported fixes for each release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mark Phippard wrote on Fri, 04 Jan 2019 16:23 -0500:
> On Fri, Jan 4, 2019 at 3:27 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> > Mark Phippard wrote on Fri, Jan 04, 2019 at 14:12:07 -0500:
> > +1, LGTM. Please change the double quotes to single quotes before you
> > commit. (The way you have it is not an sh syntax error, but it will
> > output an HTML syntax error.)
> >
>
> In terms of the HTML it has to be double-quotes, single-quotes are not
> valid here.
Your sh code would print no quotes at all, neither single nor double.
(«echo "foo"bar"baz"» prints «foobarbaz».) If the tag must use double
quotes then we should use
.
echo '<pre style="border: none">'
Cheers,
Daniel
Re: Display outstanding backported fixes for each release?
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jan 4, 2019 at 3:27 PM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Mark Phippard wrote on Fri, Jan 04, 2019 at 14:12:07 -0500:
> > Would you consider this change to remove the border around the log? I
> > think it looks more in line with the page as a whole:
> >
> > Index: generate-upcoming-changes-log.sh
> > ===================================================================
> > --- generate-upcoming-changes-log.sh (revision 1850430)
> > +++ generate-upcoming-changes-log.sh (working copy)
> > @@ -9,7 +9,7 @@
> > ~/src/svn/site/tools/upcoming.py |
> > {
> > echo "<!-- Automatically generated by
> ^/subversion/site/tools/generate-upcoming-changes-log.sh -->"
> > - echo "<pre>"
> > + echo "<pre style="border: none">"
> > ~/src/svn/site/tools/escape.py
> > echo "</pre>"
> > } > ~/src/svn/site/staging/upcoming.part.html
> >
> >
> > I would have modified the site CSS but I assume we want this border in
> the
> > other places on the site the <pre> tag is being used so this seems like
> the
> > best way to turn it off.
>
> +1, LGTM. Please change the double quotes to single quotes before you
> commit. (The way you have it is not an sh syntax error, but it will
> output an HTML syntax error.)
>
In terms of the HTML it has to be double-quotes, single-quotes are not
valid here.
https://www.w3schools.com/tags/att_style.asp
I believe you use single-quotes on some of string values within the style
attribute but not for the attribute itself.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Display outstanding backported fixes for each release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mark Phippard wrote on Fri, Jan 04, 2019 at 14:12:07 -0500:
> Would you consider this change to remove the border around the log? I
> think it looks more in line with the page as a whole:
>
> Index: generate-upcoming-changes-log.sh
> ===================================================================
> --- generate-upcoming-changes-log.sh (revision 1850430)
> +++ generate-upcoming-changes-log.sh (working copy)
> @@ -9,7 +9,7 @@
> ~/src/svn/site/tools/upcoming.py |
> {
> echo "<!-- Automatically generated by ^/subversion/site/tools/generate-upcoming-changes-log.sh -->"
> - echo "<pre>"
> + echo "<pre style="border: none">"
> ~/src/svn/site/tools/escape.py
> echo "</pre>"
> } > ~/src/svn/site/staging/upcoming.part.html
>
>
> I would have modified the site CSS but I assume we want this border in the
> other places on the site the <pre> tag is being used so this seems like the
> best way to turn it off.
+1, LGTM. Please change the double quotes to single quotes before you
commit. (The way you have it is not an sh syntax error, but it will
output an HTML syntax error.)
Cheers,
Daniel
Re: Display outstanding backported fixes for each release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mark Phippard wrote on Thu, 03 Jan 2019 16:36 -0500:
>
> > On Jan 3, 2019, at 4:18 PM, Daniel Shahaf <d....@daniel.shahaf.name>
> > wrote:
> >
> > Mark Phippard wrote on Thu, 03 Jan 2019 15:56 -0500:
> >> Looks good. If we cannot get rid of the iFrame
> >
> > We could replace the iframe by something else, but for the time
> > being, ---
>
> Are we still using server-side includes for the navigation and
> headers?
Yes.
> Would that work for this as well?
Yes.
> I'd think that maybe the HTML you have created could get embedded on
> the fly via a similar technique?
Yes, just replace <iframe src="foo"/> line by the SSI include syntax.
I have no opinion as to how the information should be presented (iframe
/ SSI / otherwise)
> I do have some vague recollection we may have been asked to stop using
> the SSI's at some point though.
Re: Display outstanding backported fixes for each release?
Posted by Mark Phippard <ma...@gmail.com>.
> On Jan 3, 2019, at 4:18 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Mark Phippard wrote on Thu, 03 Jan 2019 15:56 -0500:
>> Looks good. If we cannot get rid of the iFrame
>
> We could replace the iframe by something else, but for the time being, ---
Are we still using server-side includes for the navigation and headers? Would that work for this as well? I'd think that maybe the HTML you have created could get embedded on the fly via a similar technique?
I do have some vague recollection we may have been asked to stop using the SSI's at some point though.
Mark
Re: Display outstanding backported fixes for each release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Mark Phippard wrote on Thu, 03 Jan 2019 15:56 -0500:
> Looks good. If we cannot get rid of the iFrame
We could replace the iframe by something else, but for the time being, ---
> can we make the links open in a new window rather than within the iFrame?
Done in r1850269.
Re: Display outstanding backported fixes for each release?
Posted by Nathan Hartman <ha...@gmail.com>.
On Fri, Jan 4, 2019 at 9:24 AM Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Jan 4, 2019 at 4:47 AM Julian Foad <ju...@apache.org> wrote:
>
>> Julian Foad wrote:
>> > Ha ha! It's laugh-out-loud ugly, that teeny-tiny viewport...
>>
>> I hope my sense of humour was not badly misjudged. Seeing that Mark wrote
>> it "Looks good" without any smiley, maybe everyone else is not seeing what
>> I saw. The attached screenshot shows how it renders in Firefox.
>>
>> I genuinely was delighted to see it working at all.
>>
>
> I was using an iPad. I do not know if it was the smaller screen or if iOS
> does something to make the iFrame "fit" but in general it looked fine.
> Looking at it now on my desktop I see the same tiny viewport as you.
>
> In general iFrame's are gross and a source of problems, but they are also
> super convenient so I get it. I was mainly happy to see the info come
> together and assume there are ways it can be finessed into looking better
> on various browsers. Since we have SSI's available that seems like an easy
> initial solution to avoid needing the iFrame.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
The "responsive iframes" technique described at the following page works
with things like embedded YouTube videos to size the frame correctly for
desktop and mobile:
https://blog.theodo.fr/2018/01/responsive-iframes-css-trick/
Maybe it will help in this case too.
<http://markphip.blogspot.com/>
>
Re: Display outstanding backported fixes for each release?
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jan 4, 2019 at 4:47 AM Julian Foad <ju...@apache.org> wrote:
> Julian Foad wrote:
> > Ha ha! It's laugh-out-loud ugly, that teeny-tiny viewport...
>
> I hope my sense of humour was not badly misjudged. Seeing that Mark wrote
> it "Looks good" without any smiley, maybe everyone else is not seeing what
> I saw. The attached screenshot shows how it renders in Firefox.
>
> I genuinely was delighted to see it working at all.
>
I was using an iPad. I do not know if it was the smaller screen or if iOS
does something to make the iFrame "fit" but in general it looked fine.
Looking at it now on my desktop I see the same tiny viewport as you.
In general iFrame's are gross and a source of problems, but they are also
super convenient so I get it. I was mainly happy to see the info come
together and assume there are ways it can be finessed into looking better
on various browsers. Since we have SSI's available that seems like an easy
initial solution to avoid needing the iFrame.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Display outstanding backported fixes for each release?
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jan 4, 2019 at 9:12 AM Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Julian Foad wrote on Fri, 04 Jan 2019 09:47 +0000:
> > Julian Foad wrote:
> > > Ha ha! It's laugh-out-loud ugly, that teeny-tiny viewport...
> >
> > I hope my sense of humour was not badly misjudged.
>
> Not at all. It was well received, though I admit I didn't experience
> the full lol effect myself until I tried to open that page on a smartphone-
> sized screen. :-)
>
>
Changes are looking good!
Would you consider this change to remove the border around the log? I
think it looks more in line with the page as a whole:
Index: generate-upcoming-changes-log.sh
===================================================================
--- generate-upcoming-changes-log.sh (revision 1850430)
+++ generate-upcoming-changes-log.sh (working copy)
@@ -9,7 +9,7 @@
~/src/svn/site/tools/upcoming.py |
{
echo "<!-- Automatically generated by
^/subversion/site/tools/generate-upcoming-changes-log.sh -->"
- echo "<pre>"
+ echo "<pre style="border: none">"
~/src/svn/site/tools/escape.py
echo "</pre>"
} > ~/src/svn/site/staging/upcoming.part.html
I would have modified the site CSS but I assume we want this border in the
other places on the site the <pre> tag is being used so this seems like the
best way to turn it off.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Display outstanding backported fixes for each release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Fri, 04 Jan 2019 09:47 +0000:
> Julian Foad wrote:
> > Ha ha! It's laugh-out-loud ugly, that teeny-tiny viewport...
>
> I hope my sense of humour was not badly misjudged.
Not at all. It was well received, though I admit I didn't experience
the full lol effect myself until I tried to open that page on a smartphone-
sized screen. :-)
Cheers,
Daniel
Re: Display outstanding backported fixes for each release?
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote:
> Ha ha! It's laugh-out-loud ugly, that teeny-tiny viewport...
I hope my sense of humour was not badly misjudged. Seeing that Mark wrote it "Looks good" without any smiley, maybe everyone else is not seeing what I saw. The attached screenshot shows how it renders in Firefox.
I genuinely was delighted to see it working at all.
--
- Julian
Re: Display outstanding backported fixes for each release?
Posted by Julian Foad <ju...@apache.org>.
Daniel Shahaf wrote:
>> I've committed the scripts, added a cron job, and wired the output
>> into the site:
>>
>> https://subversion-staging.apache.org/docs/release-notes/#upcoming-patch-release
>>
>> I make no claim that the current state is visually pleasing;
Ha ha! It's laugh-out-loud ugly, that teeny-tiny viewport... it makes me feel I'm a 1980s home computer user privileged to be accessing this mainframe system over a modem... and I adore it because the essential thing is the content is there.
Awesome work, Daniel. Thanks.
>> feel free to take it from here. There are some other todo's besides the
>> aesthetics (see the link for details).
Ack.
--
- Julian
Re: Display outstanding backported fixes for each release?
Posted by Mark Phippard <ma...@gmail.com>.
On Jan 3, 2019, at 3:40 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>
> Daniel Shahaf wrote on Thu, 03 Jan 2019 18:50 +0000:
>> That's a stdin-to-stdout filter that converts the text output to HTML, suitable
>> for inclusion in the Web site.
>
> I've committed the scripts, added a cron job, and wired the output
> into the site:
>
> https://subversion-staging.apache.org/docs/release-notes/#upcoming-patch-release
>
> I make no claim that the current state is visually pleasing; feel free
> to take it from here. There are some other todo's besides the
> aesthetics (see the link for details).
Looks good. If we cannot get rid of the iFrame can we make the links open in a new window rather than within the iFrame? ViewVC did not look so great when crammed into the space of the iFrame for me.
Mark
Re: Display outstanding backported fixes for each release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Thu, 03 Jan 2019 18:50 +0000:
> That's a stdin-to-stdout filter that converts the text output to HTML, suitable
> for inclusion in the Web site.
I've committed the scripts, added a cron job, and wired the output
into the site:
https://subversion-staging.apache.org/docs/release-notes/#upcoming-patch-release
I make no claim that the current state is visually pleasing; feel free
to take it from here. There are some other todo's besides the
aesthetics (see the link for details).
Cheers,
Daniel
P.S. For reference, the cron job is:
[[[
# TODO: add this to puppet once it's stable
# Also relies on ${SVN} being set
15 4 * * * cd ~/src/svn/1.11.x && ~/src/svn/site/tools/upcoming.py | { echo "<pre>"; ~/src/svn/site/tools/escape.py; echo "</pre>"; } > ~/src/svn/site/staging/upcoming.part.html && chronic ${SVN:-svn} commit ~/src/svn/site/staging/upcoming.part.html -m "* upcoming.part.html: Automatically regenerated"
]]]
(chronic(1) on the VM doesn't have the -v option.)
P.P.S. The w3c validator complains about the 'iframe' tag, but I don't
know how to fix that (or if we care; it already complains about
the 'placeholder' (sic) attribute in our search box).
Re: Display outstanding backported fixes for each release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Thu, Jan 03, 2019 at 17:38:04 +0000:
> % ./upcoming.py | tail -46
> ------------------------------------------------------------------------
> r1847610 | svn-role | 2018-11-28 04:00:29 +0000 (Wed, 28 Nov 2018)
>
> Merge the r1847181 group from trunk:
>
> * r1847181, r1847182, r1847188, r1847264
> Fix issue SVN-4792: Foreign repo copy of file adding mergeinfo.
> Justification:
> We don't want bogus mergeinfo.
> Votes:
> +1: julianfoad, brane, rhuijben
> ------------------------------------------------------------------------
> r1849266 | svn-role | 2018-12-19 04:00:55 +0000 (Wed, 19 Dec 2018)
>
> Merge the r1847572 group from trunk:
>
> * 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'.
> Votes:
> +1: julianfoad, brane, stefan2
> ------------------------------------------------------------------------
And to go along with that:
[[[
% cat escape.py
#!/usr/bin/env python3
"""HTML-escape and linkify"""
import fileinput
import html
import re
revision_numbers = re.compile(r'\br(\d+)')
issue_references = re.compile(r'((?:SVN-|[Ii]ssue [#]?)(\d+))')
for line in fileinput.input():
line = html.escape(line)
line = revision_numbers.sub(r'<a href="https://svn.apache.org/r\1">r\1</a>', line)
line = issue_references.sub(r'<a href="/issue-\2">\1</a>', line)
print(line, end='')
]]]
That's a stdin-to-stdout filter that converts the text output to HTML, suitable
for inclusion in the Web site.
Cheers,
Daniel
Re: Display outstanding backported fixes for each release?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Julian Foad wrote on Thu, Jan 03, 2019 at 17:15:16 +0000:
> Julian Foad wrote:
> > [...] either inline or links to the verbose text samples above. [...]
>
> More precisely: I propose the output of "svn log" as illustrated in those
> samples,
Here you go.
[[[
% ./upcoming.py | tail -46
------------------------------------------------------------------------
r1847610 | svn-role | 2018-11-28 04:00:29 +0000 (Wed, 28 Nov 2018)
Merge the r1847181 group from trunk:
* r1847181, r1847182, r1847188, r1847264
Fix issue SVN-4792: Foreign repo copy of file adding mergeinfo.
Justification:
We don't want bogus mergeinfo.
Votes:
+1: julianfoad, brane, rhuijben
------------------------------------------------------------------------
r1849266 | svn-role | 2018-12-19 04:00:55 +0000 (Wed, 19 Dec 2018)
Merge the r1847572 group from trunk:
* 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'.
Votes:
+1: julianfoad, brane, stefan2
------------------------------------------------------------------------
]]]
> concatenated with the full content of the relevant 'STATUS' file.
Minus the "Veto-blocked" changes, though.
Cheers,
Daniel
Re: Display outstanding backported fixes for each release?
Posted by Julian Foad <ju...@apache.org>.
Julian Foad wrote:
> [...] either inline or links to the verbose text samples above. [...]
More precisely: I propose the output of "svn log" as illustrated in those samples, concatenated with the full content of the relevant 'STATUS' file.
--
- Julian
Re: Display outstanding backported fixes for each release?
Posted by Julian Foad <ju...@apache.org>.
Mark Phippard wrote:
> 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?
Look at the manual process I described: it starts with how the user has to remember the magic incantation for making 'svn log' find the branch-point of a tag, then copy a revision number from that output into another 'svn log' command. And after doing that, then there is still the 'STATUS' file to append, easy of course for anyone who knows how we run our backporting process, obscure to everyone else.
> 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
But I said the output of log *is* suitable. Specifically, I wrote, "Under that heading, either inline or links to the verbose text samples above." And I meant it. By "inline," I'm imagining a scrollable sub-window or something; obviously I wouldn't want it to ridiculously overwhelm the whole page. More distilled and polished output would be lovely, of course, but I really don't care about the presentation style; I just care about getting the information visible.
- Julian
Re: Display outstanding backported fixes for each release?
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jan 3, 2019 at 10:58 AM Julian Foad <ju...@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/