sysutils/diskcheckd needs fixing and a maintainer

Chris Rees utisoft at
Fri Aug 19 15:15:31 UTC 2011

On 18 Aug 2011 08:15, "Matthias Andree" <mandree at> wrote:
> 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. :-(

I don't see how, ignoring a PR, nothing happens. Ignore a depreciation, port
dies! Let's get this straight, I was not 'attracting attention', I was
saying 'I'm going to remove this port; it's been broken for over a year.'

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

Yes. Of course, these aren't pointless ports however; while still developed
and maintained they were once useful. It's time to go when they break and


More information about the freebsd-ports mailing list