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 ...

[Alexey Dokuchaev]

On Tue, Aug 02, 2011 at 04:33:14AM +0000, Baptiste Daroussin wrote:
> Ah :) I was sure this time that won't be tha easy :)

:-)

> I am deprecating them because they are abandon by upstream which means 
> and seems unmaintained. they do have modern equivalent.

But if mastersite is still up'n'running, how can we declare that they are
abandoned by upstream?

> 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?  :-)

> more infrastructure work, more complicated makefile (in that case 
> bsd.gnome.mk which already supports gnome2 things and gnome3 will come 
> one day).
> 
> If you think they are still useful ie have users and people ready todo 
> the upstream if needed then feel free to undeprecate (that's the goal of 
> the deprecation period: warn users/maintainers that a program will soon 
> disappear if no one takes care of it).

First let me state that I think your deprecating work is actually a good
thing, especially considering how much manual grunt work it requires to
check that mastersite is indeed gone, project is stalled, etc.  I highly
appreciate this undertaking of yours.

However, I believe that criteria for deprecating should be refined a bit.
That is, it's fair to deprecate long broken ports with no upstream
availability, or with open security issues.  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, and frankly speaking,
unmaintained ports often get much better care from Kato compared to plethora
of low quality "maintainer update" PRs that get committed these days.  As
you've probably noticed, I periodically touch some random ports I run
across, and it's really motivating to do something good about it when I know
there is no one I should be asking for obligatory confirmation for even
trivial changes.  Unfortunately, very few maintainers are top-notch folks,
and The Project currently has no educational programs to improve this
situation: sadly, many port committers believe in "if it builds on tindy,
it's fine" mantra.  :-(

./danfe