svn commit: r1886641 - in /subversion/trunk/tools/dist/templates: rc-news.ezt stable-news.ezt
Author: dsahlberg Date: Wed Feb 17 21:49:00 2021 New Revision: 1886641 URL: http://svn.apache.org/viewvc?rev=1886641&view=rev Log: Make life (a little bit) easier for the RM. Follow up to r1886494 requiring the website update to be done before the release announcement. http://mail-archives.apache.org/mod_mbox/subversion-dev/202102.mbox/%3ced15b241-6e0e-4c91-9f59-16844de3d...@www.fastmail.com%3e Approved by: danielsh * tools/dist/templates/stable-news.ezt Comment out the release announcement link unless a url has been specified on the command line. * tools/dist/templates/rc-news.ezt Comment out the release announcement link unless a url has been specified on the command line. Move > to the next line since some web browsers may otherwise add an underlined space in the beginning of the link. Modified: subversion/trunk/tools/dist/templates/rc-news.ezt subversion/trunk/tools/dist/templates/stable-news.ezt Modified: subversion/trunk/tools/dist/templates/rc-news.ezt URL: http://svn.apache.org/viewvc/subversion/trunk/tools/dist/templates/rc-news.ezt?rev=1886641&r1=1886640&r2=1886641&view=diff == --- subversion/trunk/tools/dist/templates/rc-news.ezt (original) +++ subversion/trunk/tools/dist/templates/rc-news.ezt Wed Feb 17 21:49:00 2021 @@ -7,12 +7,16 @@ We are pleased to announce the release of Apache Subversion [version]. This release is not intended for production use, but is provided as a milestone to encourage wider testing and feedback from intrepid users and maintainers. - Please see the + Please see the[if-any announcement_url][else] +[end] release notes and - https://svn.apache.org/repos/asf/subversion/tags/[version]/CHANGES";> - change log for information about what will eventually be + https://svn.apache.org/repos/asf/subversion/tags/[version]/CHANGES"; + >change log for information about what will eventually be in the [version_base] release. To get this release from the nearest mirror, please visit our Modified: subversion/trunk/tools/dist/templates/stable-news.ezt URL: http://svn.apache.org/viewvc/subversion/trunk/tools/dist/templates/stable-news.ezt?rev=1886641&r1=1886640&r2=1886641&view=diff == --- subversion/trunk/tools/dist/templates/stable-news.ezt (original) +++ subversion/trunk/tools/dist/templates/stable-news.ezt Wed Feb 17 21:49:00 2021 @@ -9,9 +9,13 @@ users of Subversion to upgrade as soon as reasonable. [else] This is the most complete release of the [major-minor].x line to date, and we encourage all users to upgrade as soon as reasonable. -[end] Please see the +[end] Please see the[if-any announcement_url][else] +[end] release notes for more information about this release.
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Den ons 17 feb. 2021 19:42Daniel Shahaf skrev: > Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100: > > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf < > d...@daniel.shahaf.name>: > > > Is it worthwhile to automate this step? doap.rdf changes rarely enough > > > that we needn't bother with "edit part of a file" logic; we can just > > > regenerate the entire file and «svnmucc put» it into place, with a > > > comment indicating it's a generated file. > > > > The doap.rdf contain references to two separate releases (at least > > right now) and when running release.py you are working on one release > > at a time. So we can't just have a template and add the current > > release number, we also need to know the other release (which could > > have been a year ago or the same day). > > Well, yes, and «release.py clean-dist» already has logic to determine > the other release's version number. > > > To automate "edit part of file", we would need to search for the same > > major.minor and replace with current relase, but when there is a new > > minor (1.15..) we would have to edit manually anyway. > > I don't think so. > > We could generate subversion-%(version)s.rdf-excerpt files, drop them in > dist/, and then use clean_dist()-like logic to cat the right subset of > them, adding a fixed header and trailer. This way, we wouldn't need to > splice lines out of and into the file, and we wouldn't need to special-case > the first release of a minor line or the EOLing of a minor line in the > logic. > > > It's a balance between the amount of work done by RM, the downside of > > having different processes for new minor and new patch release and the > > work to code to automate. I'm leaning towards having it as it is, but > > I would listen to Stefan's opinion (since he did the most recent RM). > > By and large, agreed, but see above for the details. > All this sounds good. However I'm not fluent in Python and even though learning is on my to-do, it is not high enough right now so I'll leave it to someone else. Kind regards Daniel Sahlberg >
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Daniel Sahlberg wrote on Wed, Feb 17, 2021 at 09:46:54 +0100: > Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf : > > Is it worthwhile to automate this step? doap.rdf changes rarely enough > > that we needn't bother with "edit part of a file" logic; we can just > > regenerate the entire file and «svnmucc put» it into place, with a > > comment indicating it's a generated file. > > The doap.rdf contain references to two separate releases (at least > right now) and when running release.py you are working on one release > at a time. So we can't just have a template and add the current > release number, we also need to know the other release (which could > have been a year ago or the same day). Well, yes, and «release.py clean-dist» already has logic to determine the other release's version number. > To automate "edit part of file", we would need to search for the same > major.minor and replace with current relase, but when there is a new > minor (1.15..) we would have to edit manually anyway. I don't think so. We could generate subversion-%(version)s.rdf-excerpt files, drop them in dist/, and then use clean_dist()-like logic to cat the right subset of them, adding a fixed header and trailer. This way, we wouldn't need to splice lines out of and into the file, and we wouldn't need to special-case the first release of a minor line or the EOLing of a minor line in the logic. > It's a balance between the amount of work done by RM, the downside of > having different processes for new minor and new patch release and the > work to code to automate. I'm leaning towards having it as it is, but > I would listen to Stefan's opinion (since he did the most recent RM). By and large, agreed, but see above for the details. Cheers, Daniel
svn commit: r1886616 - /subversion/branches/1.10.x/STATUS
Author: stsp Date: Wed Feb 17 10:45:01 2021 New Revision: 1886616 URL: http://svn.apache.org/viewvc?rev=1886616&view=rev Log: * STATUS (1.10.x): Nominate test changes relataed to CVE-2020-17525. Reminded by: danielsh Modified: subversion/branches/1.10.x/STATUS Modified: subversion/branches/1.10.x/STATUS URL: http://svn.apache.org/viewvc/subversion/branches/1.10.x/STATUS?rev=1886616&r1=1886615&r2=1886616&view=diff == --- subversion/branches/1.10.x/STATUS (original) +++ subversion/branches/1.10.x/STATUS Wed Feb 17 10:45:01 2021 @@ -43,6 +43,11 @@ Candidate changes: Votes: +1: stsp, jcorvel + * r1883838, r1883989, r1886460, r1886582 +Add test coverage for CVE-2020-17525 (mod_authz_svn NULL deref) +Votes: + +1: stsp + Veto-blocked changes: =
svn commit: r1886614 - /subversion/trunk/tools/dev/unix-build/Makefile.svn
Author: stsp Date: Wed Feb 17 09:56:10 2021 New Revision: 1886614 URL: http://svn.apache.org/viewvc?rev=1886614&view=rev Log: * tools/dev/unix-build/Makefile.svn: Reduce HTTPD debug log level to 'warn'. At log level 'debug' our tests generate enough logs to drive the ramdisk of my svn-bb-openbsd buildbot out of space within a few build runs. Modified: subversion/trunk/tools/dev/unix-build/Makefile.svn Modified: subversion/trunk/tools/dev/unix-build/Makefile.svn URL: http://svn.apache.org/viewvc/subversion/trunk/tools/dev/unix-build/Makefile.svn?rev=1886614&r1=1886613&r2=1886614&view=diff == --- subversion/trunk/tools/dev/unix-build/Makefile.svn (original) +++ subversion/trunk/tools/dev/unix-build/Makefile.svn Wed Feb 17 09:56:10 2021 @@ -1929,7 +1929,7 @@ $(HTTPD_CHECK_CONF): $(MOD_DONTDOTHAT_CO echo > $@.tmp '# httpd config for make check' echo >>$@.tmp 'ServerRoot "$(PREFIX)/httpd"' echo >>$@.tmp 'Listen localhost:$(HTTPD_CHECK_PORT)' - echo >>$@.tmp 'LogLevel debug' + echo >>$@.tmp 'LogLevel warn' echo >>$@.tmp 'LoadModule unixd_module modules/mod_unixd.so' echo >>$@.tmp 'LoadModule alias_module modules/mod_alias.so' echo >>$@.tmp 'LoadModule access_compat_module modules/mod_access_compat.so'
Re: svn commit: r1886396 - in /subversion/site/publish: ./ doap.rdf docs/release-notes/release-history.html download.html
Den tis 16 feb. 2021 kl 21:37 skrev Daniel Shahaf : > Is it worthwhile to automate this step? doap.rdf changes rarely enough > that we needn't bother with "edit part of a file" logic; we can just > regenerate the entire file and «svnmucc put» it into place, with a > comment indicating it's a generated file. The doap.rdf contain references to two separate releases (at least right now) and when running release.py you are working on one release at a time. So we can't just have a template and add the current release number, we also need to know the other release (which could have been a year ago or the same day). To automate "edit part of file", we would need to search for the same major.minor and replace with current relase, but when there is a new minor (1.15..) we would have to edit manually anyway. It's a balance between the amount of work done by RM, the downside of having different processes for new minor and new patch release and the work to code to automate. I'm leaning towards having it as it is, but I would listen to Stefan's opinion (since he did the most recent RM). Kind regards, Daniel
