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

• add-changelog-entry-for-2_16.dpatch
• patch-preview.txt
• unnamed

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.

>> +    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.

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

• add-changelog-entry-for-2_16.dpatch
• patch-preview.txt
• unnamed