>You do coverage testing, which would have found the missing date -r path.

The original coreutils test suite didn't cover the -r path. The same bug would have not been statically discovered in most programming languages, except perhaps the highly functional ones like Haskell.

>You do proper code review, which would have found the missing date -r path.

And in an ideal world there would be no bugs at all. This is pointless -- we all know that we need to do a proper code review, but humans make errors.

Then any replacement project should start with implementing a better test suite in order to know what you're doing. That has been the case with many other utilities such as ntp.

And it should most certainly not be possible to declare options and leave them as empty placeholders. That should be flagged just like an unused variable is flagged. That is a problem with whatever option library they chose to use.

That alone should disqualify it from being a replacement yet. We're talking about a stable operating system used in production here. This is simply wrong on so many levels.

>Then any replacement project should start with implementing a better test suite in order to know what you're doing

"Then any replacement project should not include bugs in their code."

Like I said before, broad statements like these are borderline pointless.

Of course we all know the should, the real problem is how -- how can you realistically make a "better test suite" when your goal is to create a bug-for-bug compatible replacement project?

And given the size of the original project, how should a better test suite be created?

>That is a problem with whatever option library they chose to use.

Instead of being vague, why not show a precise example of what you are talking about?