sysutils/diskcheckd needs fixing and a maintainer

[Chris Rees]

On 18 Aug 2011 08:15, "Matthias Andree" <mandree at freebsd.org> wrote:
>
> Am 18.08.2011 08:20, schrieb Chris Rees:
> > On 18 August 2011 09:03,  <perryh at pluto.rain.com> wrote:
> >> Chris Rees <utisoft at gmail.com> wrote:
> >>
> >>> We don't want to provide broken software.
> >>
> >> Mark Linimon <linimon at lonesome.com> 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".
> >>
> >> * http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/115853
> >>  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
bitrot.

Chris