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 2017/12/22 15:08:01 UTC
1.10 tasks: update CHANGES and roll RC1 or beta1
* Does the CHANGES file need to be updated before we can roll RC1?
In my opinion this is a "documentation change" and we can release an RC1
with incomplete CHANGES for the first 3 weeks of soak period, and
release RC2 with completed CHANGES (whether any other changes are needed
or not) for the last week of soak period.
danielsh said on IRC a few days ago,
> https://subversion.apache.org/docs/community-guide/releasing.html#rolling-release
> -> the first step is to write CHANGES. We haven't done that, have we?
> I guess we should either bring CHANGES up to date, or call the
> tarball 1.10.0-beta1.
> http://home.apache.org/~danielsh/subversion-20171219_001/ has beta1
> artifacts. Unfortunately they aren't signed by me (PEBKAC)
Should we release beta1 or go ahead with RC1?
* What do we know about the current up-to-date-ness of CHANGES?
It looks like a lot of changes are listed already. Do we have to review
every change since 1.9 or is there some subset of that work that we can
accept as having been done already? stsp and danielsh, you two added
most of the entries, so CC'ing you.
* Does anyone volunteer to do some updating?
I could probably take on a guided subset of it in January; not a
complete review.
- Julian
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Daniel Shahaf <da...@apache.org>.
Julian Foad wrote on Fri, 22 Dec 2017 15:08 +0000:
> * What do we know about the current up-to-date-ness of CHANGES?
>
> It looks like a lot of changes are listed already. Do we have to review
> every change since 1.9 or is there some subset of that work that we can
> accept as having been done already? stsp and danielsh, you two added
> most of the entries, so CC'ing you.
1.10.0-alpha3 was cut on July 19. IIRC, the CHANGES file had been brought up
to date at that point, so we only need to review the ~330 commits to trunk
since that date.
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Julian Foad <ju...@apache.org>.
Stefan Fuhrmann wrote:
> As of r1819491, the CHANGES for 1.10 should be complete.
>
> The file might use some sorting / grouping and certainly a review.
I have just committed a few initial tweaks, and mentioned some thoughts
on IRC.
While we would like to make more improvements to its presentation, I do
not think we need to further review the content of the changes list. As
such I'm closing issue https://issues.apache.org/jira/browse/SVN-4715
"CHANGES update".
The CHANGES update is no longer blocking rolling RC1. Hurray!
As always, please speak up if anyone disagrees.
- Julian
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Julian Foad <ju...@apache.org>.
Stefan Fuhrmann wrote:
> As of r1819491, the CHANGES for 1.10 should be complete.
>
> The file might use some sorting / grouping and certainly a review.
Awesome!
Thanks, Stefan!
Happy Christmas, Subversion!
- Julian
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Stefan Fuhrmann <st...@apache.org>.
On 28.12.2017 19:17, Stefan Fuhrmann wrote:
> On 25.12.2017 14:20, Stefan Sperling wrote:
>> On Mon, Dec 25, 2017 at 12:21:46PM +0100, Stefan Fuhrmann wrote:
>>> So, this is the result. It also covers the changes
>>> skipped by release.py (first block of 5 entries).
>>>
>>> I will try to reformulate & group the list and then
>>> commit them to CHANGES by Wednesday.
>>
>> Thanks! This helps a lot with completing the changelog.
>>
>> However, I have some mild concerns.
>
> <snip>
>
>> I am not going to go through all of these now. I suppose you already
>> understand the point I'm trying to make.
>> We can still do a final review at the end and toss out entries which aren't
>> really needed, but please don't just add new entries without considering
>> and weighing each of them. Please carefully check each entry.
>>
>
> For the ones I now added to the CHANGES list, I did check
> each entry. The point of my initial post was to "save" /
> document the intermediate state after filtering through
> over 200 candidates, combining related ones etc.
>
> -- Stefan^2.
As of r1819491, the CHANGES for 1.10 should be complete.
The file might use some sorting / grouping and certainly a review.
-- Stefan^2.
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Stefan Fuhrmann <st...@apache.org>.
On 25.12.2017 14:20, Stefan Sperling wrote:
> On Mon, Dec 25, 2017 at 12:21:46PM +0100, Stefan Fuhrmann wrote:
>> So, this is the result. It also covers the changes
>> skipped by release.py (first block of 5 entries).
>>
>> I will try to reformulate & group the list and then
>> commit them to CHANGES by Wednesday.
>
> Thanks! This helps a lot with completing the changelog.
>
> However, I have some mild concerns.
<snip>
> I am not going to go through all of these now. I suppose you already
> understand the point I'm trying to make.
> We can still do a final review at the end and toss out entries which aren't
> really needed, but please don't just add new entries without considering
> and weighing each of them. Please carefully check each entry.
>
For the ones I now added to the CHANGES list, I did check
each entry. The point of my initial post was to "save" /
document the intermediate state after filtering through
over 200 candidates, combining related ones etc.
-- Stefan^2.
As of r1819436, the remaining changes candidates are:
* Detect ruby versions up to 2.4 (r1806570)
* Fix KDE5 support with clang 3.8 (r1802536 et al)
* Add SWIG_FEATURES variable (and lang-specific variants) to tune how swig
bindings are generated. (r1816254)
* Allow building against OpenSSL 1.1.0 on Windows by properly detect the
(r1814724 et al)
* Build against the system utf8proc library by default (r1803210 et al)
* Disable static builds of the apache and auth provider modules (r1802612)
* Drop support for upgrading working copies created with Subversion 1.7
(r1807584 et al)
* Fix a potential bug and an API contract violation in the Win32
implementation (r1806014)
* Fix a slightly broken private API. (r1807966)
* Merge upstream utf8proc 2.1.0 into trunk. (r1809090 et al)
* Omit the list of system error code names from release builds, this
(r1804618 et al)
* On OSX, ranlib complains loudly about object files with no symbols.
(r1809792)
* Fix issue #4700 for property changes. (r1813794 et al)
* Suggest and use https:// links to download SQLite amalgamation (r1817043)
* ra_serf: Stream svndiff deltas w/o creating temporary files (r1803143 et al)
* ra_serf: Prevent the server from generating and sending the full MERGE
(r1806017 et al)
* ra_serf: Properly process lock tokens for empty relative paths ("")
(r1815799 et al)
* tests: Report unknown SWIG binding types on Windows. (r1802709)
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Stefan Sperling <st...@apache.org>.
On Mon, Dec 25, 2017 at 12:21:46PM +0100, Stefan Fuhrmann wrote:
> So, this is the result. It also covers the changes
> skipped by release.py (first block of 5 entries).
>
> I will try to reformulate & group the list and then
> commit them to CHANGES by Wednesday.
Thanks! This helps a lot with completing the changelog.
However, I have some mild concerns.
I don't think it makes sense to list changes such as:
> * Add support for tracing moves backwards in history to the conflict
> resolver. (r1808263)
> * Make svn --non-interactive use recommended tree conflict resolution
> (r1805620)
> * fsfs: Don't store SHA1 for property representations in format 8.
> (r1816348)
Because these are not changes relative to 1.9, they are changes made
between 1.10-dev and another 1.10-dev.
Also, entries such as:
> * Fix a slightly broken private API. (r1807966)
> * Refactor the merging of merge rangelists (r1802470 et al)
> * Merge the 'shelve' branch to trunk. (r1815228 et al)
> * release.py: Don't discard errors. (r1804278)
provide little value to end users. They don't convey enough information
in isolation so it's unclear why they are important.
The changelog should not be a mirror of what the commit log says.
Rather, it should list the significant changes from 1.9.0 to 1.10.0,
excluding any changes which were already backported to 1.9/1.8.
I spent about a day and a half already on many 1.10 changelog entries,
and it would be nice to reduce this time with more automation.
But I found most of my time was spent cross-checking entries with the
commit log and STATUS files rather than building an initial list.
On the bright side, there are some entries the script found which are
relevant and which I missed. Some of these are probably new (my last
commit to CHANGES was r1783882). Here are some entries which I think
are important:
> * Add a new --vacuum-pristines option to 'svn cleanup'. (r1802787
> * Add '--include' and '--exclude' options to 'svnadmin dump'.
> * svnadmin: Introduce the `--normalize-props` option for the load
I am not going to go through all of these now. I suppose you already
understand the point I'm trying to make.
We can still do a final review at the end and toss out entries which aren't
really needed, but please don't just add new entries without considering
and weighing each of them. Please carefully check each entry.
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Stefan Fuhrmann <st...@apache.org>.
On 24.12.2017 09:39, Stefan Fuhrmann wrote:
> On 23.12.2017 14:30, Johan Corveleyn wrote:
>> I'm afk for a couple of days so can't try it myself now, but
>>
>> release.py write-changelog --include-unlabeled-summaries
>> branches/1.10.x tags/1.10.0-alpha3
>>
>> might provide a good starting point.
> I'm giving it a try right now. It starts with 162 entries
> but it should be easy to boil down to < 100. I'll report
> back once that is done.
>
> -- Stefan^2.
>
So, this is the result. It also covers the changes
skipped by release.py (first block of 5 entries).
I will try to reformulate & group the list and then
commit them to CHANGES by Wednesday.
-- Stefan^2.
[[[
* Ruby bindings: Fix handling of NULL MD5 digests (r1811786)
* Check for invalid 'xt' fields in x509 certs (r1809290)
* Detect ruby versions up to 2.4 (r1806570)
* release.py: Always use UTC timestamps (r1804608)
* Fix KDE5 support with clang 3.8 (r1802536 et al)
* Add '--include' and '--exclude' options to 'svnadmin dump'.
(r1811992 et al)
* Add 'http-compression=auto' mode on the client, now used by
default. (r1803899 et al)
* Add --with-kwallet=INCDIR:LIBDIR to support KDE5 on platforms
that do (r1802646)
* Add SWIG_FEATURES variable (and lang-specific variants) to tune
how swig bindings are generated. (r1816254)
* Add a new --accept recommended option to 'svn'. (r1805623)
* Add a new --vacuum-pristines option to 'svn cleanup'. (r1802787
et al)
* Add new svn_txdelta_to_svndiff_stream() API. (r1803140 et al)
* Add stricter key file syntax checks for releases. (r1805277)
* Add support for tracing moves backwards in history to the
conflict resolver. (r1808263)
* Allow building against OpenSSL 1.1.0 on Windows by properly
detect the (r1814724 et al)
* Refactor the merging of merge rangelists (r1802470 et al)
* Build against the system utf8proc library by default (r1803210 et al)
* Disable static builds of the apache and auth provider modules
(r1802612)
* Drop support for upgrading working copies created with Subversion
1.7 (r1807584 et al)
* Fix a potential bug and an API contract violation in the Win32
implementation (r1806014)
* Fix a slightly broken private API. (r1807966)
* Fix an assertion in 'svnfsfs stats' with pre-v4 FSFS
repositories. (r1816966)
* Fix issue #4689, "diff --git added/deleted filenames should not
be /dev/null". (r1811662)
* Fix segfault with invalid URLs in svn:externals (r1803471)
* In 'svn help lock/unlock', document the '--force' option (steal
or break (r1802557)
* Introduce the svn_cstring_join2() API (r1806041)
* Make 'svn help' more consistent when showing deprecated options.
(r1802989 et al)
* Make svn --non-interactive use recommended tree conflict
resolution (r1805620)
* Merge the 'shelve' branch to trunk. (r1815228 et al)
* Merge upstream utf8proc 2.1.0 into trunk. (r1809090 et al)
* Move the dist.sh processing into release.py so that the python
script (r1804590)
* Omit the list of system error code names from release builds,
this (r1804618 et al)
* On OSX, ranlib complains loudly about object files with no
symbols. (r1809792)
* Return resettable streams from svn_stream_checksummed2(). (r1804807)
* Fix issue #4700 for property changes. (r1813794 et al)
* The compile-time and run-time version of httpd may not be the
same. (r1808955 et al)
* Tweak the help text for 'svn commit'. (r1805876)
* Tweak the help text for 'svn cleanup'. (r1802941)
* Suggest and use https:// links to download SQLite amalgamation
(r1817043)
* dist.sh: Make it harder to MITM the RM. (r1804192)
* fsfs: Don't store SHA1 for property representations in format 8.
(r1816348)
* fsfs: Introduce new 'compression' config option. (r1803639 et al)
* fsfs: Fix issue #4623 for FSFS. (r1813794 et al)
* fsfs: Make LZ4 the new default compression algorithm for all
(r1805897 et al)
* fsfs: Use the `WITHOUT ROWID` optimization for rep-cache.db in
format 8. (r1817042)
* ra_serf: Stream svndiff deltas w/o creating temporary files
(r1803143 et al)
* ra_serf: Prevent the server from generating and sending the full
MERGE (r1806017 et al)
* ra_serf: Properly process lock tokens for empty relative paths
("") (r1815799 et al)
* ra_svn: Use svndiff2 deltas when supported on both ends.
(r1803269 et al)
* release.py: Correct the output of 'write-downloads' (r1804277)
* release.py: Don't discard errors. (r1804278)
* svnadmin: Introduce the `--normalize-props` option for the load
and (r1807836 et al)
* svnserve: Make use-sasl=true a fatal error in SASL-less builds.
(r1803188)
* tests: Add pre-cooked repos for all FSFS versions. (r1816402 et al)
* tests: Run rep-sharing tests with BDB as well. (r1817028)
* tests: Add FSFS_DIR_DELTIFICATION option. (r1813897)
* tests: Report unknown SWIG binding types on Windows. (r1802709)
]]]
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Stefan Fuhrmann <st...@apache.org>.
On 23.12.2017 14:30, Johan Corveleyn wrote:
> I'm afk for a couple of days so can't try it myself now, but
>
> release.py write-changelog --include-unlabeled-summaries
> branches/1.10.x tags/1.10.0-alpha3
>
> might provide a good starting point.
I'm giving it a try right now. It starts with 162 entries
but it should be easy to boil down to < 100. I'll report
back once that is done.
-- Stefan^2.
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Johan Corveleyn <jc...@gmail.com>.
I'm afk for a couple of days so can't try it myself now, but
release.py write-changelog --include-unlabeled-summaries
branches/1.10.x tags/1.10.0-alpha3
might provide a good starting point.
--
Johan
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Julian Foad <ju...@apache.org>.
Daniel Shahaf wrote:
> Julian Foad wrote on Fri, 22 Dec 2017 15:08 +0000:
>> * Does the CHANGES file need to be updated before we can roll RC1?
>>
>> In my opinion this is a "documentation change" and we can release an RC1
>> with incomplete CHANGES for the first 3 weeks of soak period, [...]
>
> I'm not sure I agree. Allow me to play devil's advocate here and we'll see
> where it leads.
>
> If CHANGES is not uptodate, then consumers of rc1 can't test any bugfixes that
> aren't documented, [...]
>
> Makes sense?
Yes, makes sense. Thanks.
- Julian
Re: 1.10 tasks: update CHANGES and roll RC1 or beta1
Posted by Daniel Shahaf <da...@apache.org>.
Julian Foad wrote on Fri, 22 Dec 2017 15:08 +0000:
> * Does the CHANGES file need to be updated before we can roll RC1?
>
> In my opinion this is a "documentation change" and we can release an RC1
> with incomplete CHANGES for the first 3 weeks of soak period, and
> release RC2 with completed CHANGES (whether any other changes are needed
> or not) for the last week of soak period.
I'm not sure I agree. Allow me to play devil's advocate here and we'll see
where it leads.
If CHANGES is not uptodate, then consumers of rc1 can't test any bugfixes that
aren't documented, which devalues the soak. Thus, updating CHANGES isn't a
technical requirement; it's a substantive requirement. The rule that doc
changes don't reset the soak would have applied to, say, spelling corrections
to CHANGES, but adding five months' worth of history to CHANGES _would_
warrant a reset of the soak, despite being a docs patch. To paraphrase
sussman, there's more to cutting releases than throwing tarballs over a wall. :-)
Makes sense? I'm not sure I *entirely* agree with the last paragraph, but
perhaps the truth lies in the middle somewhere.
Cheers,
Daniel