sysutils/diskcheckd needs fixing and a maintainer

Matthias Andree mandree at
Thu Aug 18 07:14:57 UTC 2011

Am 18.08.2011 08:20, schrieb Chris Rees:
> On 18 August 2011 09:03,  <perryh at> wrote:
>> Chris Rees <utisoft at> wrote:
>>> We don't want to provide broken software.
>> Mark Linimon <linimon at> wrote:
>>> ... it's obsolete, broken, junk ...
>> Unless there is more to this than is reported in those two PRs,
>> I'd call it a considerable exaggeration to describe diskcheckd
>> as "broken".
>> *
>>  is shown as "closed", so presumably is no longer a problem.
> Wow, would it have been too difficult to actually READ the closing
> message from Jeremy? I suggest you look again -- I've pasted it here
> so you can see it.
> "The problem here is that the code does not do what the manpage says (or
> vice-versa). The 3rd column does not specify frequency of checking, but
> rather, over what duration of time to spread a single disk scan over.
> Thus, 7 days would mean "spread the entire disk check at X rate over the
> course of 7 days". There is still a bug in the code where large disks
> will cause problems resulting in updateproctitle() never getting called,
> and so on, but that's unrelated to this PR. I'm closing the PR because
> trying to fix all of this should really be ben@'s responsibility.
> (Sorry for sounding harsh.)"
> How does that indicate it's fixed? It's an 'abandoned' PR.

This would be a case for marking it suspended (or possibly analyzed,
depending on which of these two fits best), rather than closing it.
The status is also a statement...

> Thank you for testing and investigating, this is what the port has
> needed, and two days of being deprecated has achieved more than 18
> months of a PR being open.

So the bottom line for this case is, we sometimes only get sufficient
attention through deprecating ports.  Unfortunately that approach might
wear off some day.  Too bad. :-(

Do we need a "think twice before adding a port" habit?

More information about the freebsd-ports mailing list