darcs

Patch 2072 add CHANGELOG entry for 2.16

Title add CHANGELOG entry for 2.16
Superseder Nosy List bfrk
Related Issues
Status accepted Assigned To
Milestone

Created on 2020-07-29.21:49:48 by bfrk, last changed 2020-07-30.12:01:19 by bfrk.

Files
File name Status Uploaded Type Edit Remove
add-changelog-entry-for-2_16.dpatch dead bfrk, 2020-07-29.21:49:46 application/x-darcs-patch
add-changelog-entry-for-2_16.dpatch bfrk, 2020-07-30.11:59:02 application/x-darcs-patch
patch-preview.txt bfrk, 2020-07-29.21:49:46 text/x-darcs-patch
patch-preview.txt bfrk, 2020-07-30.11:59:02 text/x-darcs-patch
unnamed bfrk, 2020-07-29.21:49:46 text/plain
unnamed bfrk, 2020-07-30.11:59:02 text/plain
See mailing list archives for discussion on individual patches.
Messages
msg22284 (view) Author: bfrk Date: 2020-07-29.21:49:46
1 patch for repository http://darcs.net/screened:

patch 9e24d4c9ffcabf96b7dfdd1004bc2eec4fdef45c
Author: Ben Franksen <ben.franksen@online.de>
Date:   Wed Jul 29 23:52:02 CEST 2020
  * add CHANGELOG entry for 2.16
  
  This should cover every user-visible change, based on the patch descriptions
  in the difference between branch-2.14 and reviewed as of today.
Attachments
msg22289 (view) Author: ganesh Date: 2020-07-30.10:56:56
On 29/07/2020 22:49, Ben Franksen wrote:

>   * add CHANGELOG entry for 2.16
>   
>   This should cover every user-visible change, based on the patch descriptions
>   in the difference between branch-2.14 and reviewed as of today.


> +    largely based on the pioneering work of Ian Lynnagh for 'camp'.

Spelling mistake - should be "Lynagh"

> This means
> +    that if you started a rebase with darcs < 2.16, then you cannot use
> +    darcs-2.16 with that repo; the only exception is the new 'darcs rebase
> +    upgrade' command that upgrades the suspended patches to the new format.

I think this is phrased in a slightly confusing way as it first implies
you can't do anything and then corrects that. How about something like
this? :

"This means that if you have a rebase in progress started with darcs <
2.16, you will first need to use the new 'darcs rebase upgrade' command
to upgrade the suspended patches to the new format."


> +    * fix lots of wrong uses of 'error': it was often used to signal that a
> +      command should fail when we are not in IO or a monad layered over IO.
> +      In these situations we now throw a UserError or a special exception
> +      type. This results in a normal command failure with an error message.
> +      The error function is reserved to internal errors i.e. bugs in darcs.

This feels a bit code-focused. Perhaps something like this? :

"Reworked internal failure handling so we can clearly distinguish
between normal command failures and internal errors, i.e bugs, in darcs."

The rest looks good, I didn't cross-check against the full list of patches.

Thanks for writing it - please treat it and any amendments to address
the above as reviewed.
msg22291 (view) Author: bfrk Date: 2020-07-30.11:52:32
>> +    largely based on the pioneering work of Ian Lynnagh for 'camp'.
> 
> Spelling mistake - should be "Lynagh"

Will fix. (I can never remember how this name is spelled.)

>> This means
>> +    that if you started a rebase with darcs < 2.16, then you cannot use
>> +    darcs-2.16 with that repo; the only exception is the new 'darcs rebase
>> +    upgrade' command that upgrades the suspended patches to the new format.
> 
> I think this is phrased in a slightly confusing way as it first implies
> you can't do anything and then corrects that. How about something like
> this? :
> 
> "This means that if you have a rebase in progress started with darcs <
> 2.16, you will first need to use the new 'darcs rebase upgrade' command
> to upgrade the suspended patches to the new format."

Yes, that's much better.

>> +    * fix lots of wrong uses of 'error': it was often used to signal that a
>> +      command should fail when we are not in IO or a monad layered over IO.
>> +      In these situations we now throw a UserError or a special exception
>> +      type. This results in a normal command failure with an error message.
>> +      The error function is reserved to internal errors i.e. bugs in darcs.
> 
> This feels a bit code-focused. Perhaps something like this? :
> 
> "Reworked internal failure handling so we can clearly distinguish
> between normal command failures and internal errors, i.e bugs, in darcs."

Again, agreed this is better.

I will combine this with the two misc change items

    * add a top-level error handler (to add a message that this is a bug
      in darcs and please report it and where)
    * change the email address for bug reports to bugs@darcs.net

into a new top level item.
msg22294 (view) Author: bfrk Date: 2020-07-30.11:59:02
Following up on review with an amended patch. Will screen and self-accept.

1 patch for repository http://darcs.net/screened:

patch 3c08c90bcfb95f6de1411d5d12fe6f5eec990934
Author: Ben Franksen <ben.franksen@online.de>
Date:   Wed Jul 29 23:52:02 CEST 2020
  * add CHANGELOG entry for 2.16
  
  This should cover every user-visible change, based on the patch descriptions
  in the difference between branch-2.14 and reviewed as of today.
Attachments
History
Date User Action Args
2020-07-29 21:49:48bfrkcreate
2020-07-30 10:56:58ganeshsetmessages: + msg22289
2020-07-30 11:52:32bfrksetmessages: + msg22291
2020-07-30 11:59:03bfrksetfiles: + patch-preview.txt, add-changelog-entry-for-2_16.dpatch, unnamed
messages: + msg22294
2020-07-30 12:01:19bfrksetstatus: needs-screening -> accepted