Fix npm audit issues. is temporary here for your conviniece, so you can easily build it and test it.

I wonder if we should use a different date format where the Month is spelled out? July 15, 2019 16:11:12 Different countries use different orders for the slash separated date components. So it's best to try to avoid any confusion if possible.

Shouldn't process and dump be a function of Changelog5 instead of implemented outside of it? And then the tool just calls "cl = Changelog5(); cl.process and dump()"?

I think my concern here is that we should not have logic in the CLI framework, because that makes it impossible to reuse for api or tests - perhaps this cl decode should also be in the Changelog5 type?

I wonder if we should use a different date format where the Month is spelled out? July 15, 2019 16:11:12 Different countries use different orders for the slash separated date components. So it's best to try to avoid any confusion if possible.

I agree the "slash" dates are very confusing. I believe we should adhere to ISO 8601 datetimes (ideally with timezone) which follow the principle of having more significant value earlier - easily sortable and parseable and human-comprehensible.

Fixed.
Massive changes and rebase with all of the critical master fixes.
Please, review.

LGTM

Looks good to me as well.
Just a doubt about the command (dsconf) and the verb (dump-changelog).
This is not configuration command but rather an admin action like db2ldif, db2back...
Why not implementing this action in dsctl ?
Also instead of dump-changelog, why not something like changelog2ldif ?

Looks good to me as well.
Just a doubt about the command (dsconf) and the verb (dump-changelog).
This is not configuration command but rather an admin action like db2ldif, db2back...
Why not implementing this action in dsctl ?
Also instead of dump-changelog, why not something like changelog2ldif ?

There is a couple of points why I've chosen this approach.

• dsconf was chosen because we still need credentials to access the directory (we get the changelogdir from there, we run through the list of replicas and we run the CL2LDIF task). dsctl doesn't have the credential's option and it is more of an "offline" tool.
• dump-changelog was chosen because of the consistency with other names in the replication subcommand. Like we have: create-changelog, delete-changelog, set-changelog, get-changelog.

I am not against changelog2ldif though.
And as @mreynolds was the main developer for replication CLI, I'd give him the final word here, I think... changelog2ldif, dump-changelog or a third funny option.

@spichugi thanks for your answer. I agree with you, being a task it makes sense to add it into dsconf.

For the action verb, I have no strong opinion but the advantage of x2ldif is that it gives indication about the type of the result. I will follow your and @mreynolds decision.

I prefer what Simon has. It matches the surrounding CLI usage: get-changelog, set-changelog, dump-changelog, ... It also matches most of the other dsconf style usage.

But the CLI help text for "dump-changelog" does not mention that it creates an LDIF file. That should be improved.

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3554

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.