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 ...
linimon at lonesome.com
Fri Aug 5 04:24:14 UTC 2011
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
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
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.
More information about the cvs-ports