cvs commit: ports/audio/aube Makefile ports/x11-wm/epiwm Makefile ports/astro/gkrellmoon Makefile ports/audio/gkrellmss Makefile ports/astro/gkrellsun Makefile ports/audio/gnapster Makefile ports/audio/gtkgep Makefile ports/audio/midimountain Makefile ...

[Mark Linimon]

On Wed, Aug 03, 2011 at 04:26:20PM +0000, Alexey Dokuchaev wrote:
> But if mastersite is still up'n'running, how can we declare that they
> are abandoned by upstream?

Because the upstream says that they no longer support the software?

> > No upstream == most of the time no maintainenance, no more patches, no 
> > more security concern. For us it also mean more things to take care of, 
> 
> Maybe that means that the software is stable and "just works".  Why patch
> it then?  :-)

We've seen plenty of evidence of how badly ports bitrot when new compilers
come in, not to mention changes in libc and other places in src.

> But mere lack of maintainer or recent upstream activity is not enough:
> lots of programs happen to just work so no new version is actually that
> needed

In that case, some FreeBSD committer should agree to become the upstream,
once the upstream is no longer interested; or find someone else out on
the Internet to do so.  IMHO.

> unmaintained ports often get much better care from Kato compared to plethora
> of low quality "maintainer update" PRs that get committed these days.

Please, when you find a low-quality commit (in terms of functionality --
I know that you and I will not agree on cosmetics), then please bring them
to the attention of portmgr.

And, not all the Kato-submitted PRs are of equal quality.

> Unfortunately, very few maintainers are top-notch folks,

I think this is an unnecessary slam on our maintainers.  I will agree
that some maintainers are much more rigorous than others, of course.

> and The Project currently has no educational programs to improve this
> situation

Most of the education goes on behind the scenes, in private email, on
IRC, and so forth.

My view, which I know I have repeated before, is that posting generalities
to the mailing lists does not solve specific problems.  I believe that
identifying the specific problems and working the the maintainers and
committers one-on-one is a much more effective approach, and that's the
approach I take.  e.g., I try to follow the management dictum "praise in
public, criticize in private", especially with new contributors.

YMMV.

mcl