You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan <lu...@gmx.de> on 2015/09/19 11:59:13 UTC
layout change for CHANGES
Hi,
I'm wondering whether it'd be a good idea if entries in the changelog
were sorted by its category. This mostly applies to the "Client-side
bugfixes" but I think it would slightly improve the readability by users
because:
a) it's easier to check the sorted list to see if there were some fixes
in between different versions on a certain part of SVN (for instance
when a user reports a problem with the update process in an older
version, you can more easily check the following versions to see if
there's a likely candidate for an existing bugfix)
b) When you read the list from top to bottom you are not jumping between
multiple areas of SVN to get what was changed/fixed in that release.
Here's how a differently sorted changelog for 1.9.2 could look like:
Version 1.9.2
(30 Sep 2015, from /branches/1.9.x)
http://svn.apache.org/repos/asf/subversion/tags/1.9.2
User-visible changes:
- Client-side bugfixes:
* checkout: remove unnecessary I/O operation (r1701638)
* checkout/update: fix "access denied" error on Windows (r1701064
et al)
* commit: fix possible crash (r1702231)
* merge: fix crash when merging to a local add (r1702299 et al)
* merge: fix possible crash (r1701997)
* ra_serf: do not crash on unexpected 'X-SVN-VR-Base' headers
(r1702288)
* revert: fix crash when reverting the root of a move (r1702237 et al)
* svn: fix crash when saving credentials in kwallet (r1700740,
r1700951)
* svn: do not crash upon specific database corruptions (r1702974,
r1702991)
* svn: show utf8proc version in svn --version --verbose (r1702533,
r1702891)
* svnmucc: fix error during propset+put for existing file (r1702467
et al)
* update: fix crash when updating a conflicted tree (r1702198,
r1702200)
* update: fix crash without .svn/tmp folder (r1701838, r1702203)
* update: fix crash with some of the incoming deletes (r1702247)
* upgrade: fix crash for pre-1.3 wc with externals (r1702218 et al)
- Server-side bugfixes:
* fix reporting for empty representations in svnfsfs stats
(r1698312 et al)
Developer-visible changes:
- General:
* fix svnfsfs_tests.py in fsfs-v4 and fsfs-v6 modes (r1700215 et al)
- API changes:
* disable unsupported operations for standard streams (r1701633 et al)
If you determine that'd be a good idea, I'd offer to update the CHANGES
for all 1.9.x release notes accordingly.
Regards,
Stefan
Re: layout change for CHANGES
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Branko Čibej <br...@apache.org> writes:
> I don't mind reordering the 1.9.x entries, but please don't touch
> anything earlier than that because it'd be a real pain to merge to 1.8.x
> and older (that merge is already a bit of a pain, so let's not make it
> worse).
I was not going to touch the /CHANGES, of course.
As I said in my previous e-mail, I don't think that we should be doing this,
because it would introduce unnecessary difference between the changelog
inside the tarballs and in the repository.
Regards,
Evgeny Kotkov
Re: layout change for CHANGES
Posted by Branko Čibej <br...@apache.org>.
On 19.09.2015 14:29, Evgeny Kotkov wrote:
> Stefan Hett <lu...@gmx.de> writes:
>
>> I'm wondering whether it'd be a good idea if entries in the changelog were
>> sorted by its category. This mostly applies to the "Client-side bugfixes"
>> but I think it would slightly improve the readability by users because:
> [...]
>
>> Here's how a differently sorted changelog for 1.9.2 could look like:
>>
>> Version 1.9.2
>> (30 Sep 2015, from /branches/1.9.x)
>> http://svn.apache.org/repos/asf/subversion/tags/1.9.2
>>
>> User-visible changes:
>> - Client-side bugfixes:
>> * checkout: remove unnecessary I/O operation (r1701638)
>> * checkout/update: fix "access denied" error on Windows (r1701064 et al)
>> * commit: fix possible crash (r1702231)
>> * merge: fix crash when merging to a local add (r1702299 et al)
>> * merge: fix possible crash (r1701997)
>> * ra_serf: do not crash on unexpected 'X-SVN-VR-Base' headers (r1702288)
>> * revert: fix crash when reverting the root of a move (r1702237 et al)
>> * svn: fix crash when saving credentials in kwallet (r1700740, r1700951)
>> * svn: do not crash upon specific database corruptions (r1702974,
> [...]
>
> Indeed, the changelog with grouping looks more readable in this particular
> example. Based on older entries, I don't think that we've been doing this
> sort of grouping — i.e., some of the entries are locally grouped, but there
> is no grouping overall.
>
> The Community Guide doesn't say something about it, except for "Read that log
> from oldest to newest, summarizing points as you go." [1]. I did that for
> the 1.9.2 part of the changelog, and I also used the 1.8.9 changelog as
> reference, as these releases are somewhat similar in the amount and types
> of changes.
We tend to order the entries by revision. That may not be the best
choice, but that's how it's been more or less since day one.
I don't mind reordering the 1.9.x entries, but please don't touch
anything earlier than that because it'd be a real pain to merge to 1.8.x
and older (that merge is already a bit of a pain, so let's not make it
worse).
-- Brane
Re: layout change for CHANGES
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Stefan Hett <lu...@gmx.de> writes:
> I'm wondering whether it'd be a good idea if entries in the changelog were
> sorted by its category. This mostly applies to the "Client-side bugfixes"
> but I think it would slightly improve the readability by users because:
[...]
> Here's how a differently sorted changelog for 1.9.2 could look like:
>
> Version 1.9.2
> (30 Sep 2015, from /branches/1.9.x)
> http://svn.apache.org/repos/asf/subversion/tags/1.9.2
>
> User-visible changes:
> - Client-side bugfixes:
> * checkout: remove unnecessary I/O operation (r1701638)
> * checkout/update: fix "access denied" error on Windows (r1701064 et al)
> * commit: fix possible crash (r1702231)
> * merge: fix crash when merging to a local add (r1702299 et al)
> * merge: fix possible crash (r1701997)
> * ra_serf: do not crash on unexpected 'X-SVN-VR-Base' headers (r1702288)
> * revert: fix crash when reverting the root of a move (r1702237 et al)
> * svn: fix crash when saving credentials in kwallet (r1700740, r1700951)
> * svn: do not crash upon specific database corruptions (r1702974,
[...]
Indeed, the changelog with grouping looks more readable in this particular
example. Based on older entries, I don't think that we've been doing this
sort of grouping — i.e., some of the entries are locally grouped, but there
is no grouping overall.
The Community Guide doesn't say something about it, except for "Read that log
from oldest to newest, summarizing points as you go." [1]. I did that for
the 1.9.2 part of the changelog, and I also used the 1.8.9 changelog as
reference, as these releases are somewhat similar in the amount and types
of changes.
> If you determine that'd be a good idea, I'd offer to update the CHANGES for
> all 1.9.x release notes accordingly.
I don't think that we should be rewriting the changelog, as this would result
in having different /CHANGES sections in the repository and in the released
tarballs.
Nevertheless, I think that it's a good thing to keep in mind for the future
changelog entries. Thank you for sharing the thoughts.
[1] https://subversion.apache.org/docs/community-guide/releasing.html#the-changes-file
Regards,
Evgeny Kotkov