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

[Baptiste Daroussin]

On Wed, 3 Aug 2011 16:26:20 +0000, Alexey Dokuchaev wrote:
> 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


I agree concerning ports maintained by ports@ and how thay are 
maintained, however, if you or others feels like I was wrong deprecating 
some ports, just undeprecate them.

I am just trying to have a ports tree providing really usable things. 
And providing very old, unmaintained by upstream ports which have new 
available or equivalent "modern" version is a good thing. To be clear, 
in my mind most of the gnome1 (no I don't have xmms or so in mind) ports 
has to bite the dust because, who is still using and testing them? It 
also has a maintainance cost in the Mk/* files. I am sure we can get rid 
of most of those ports (just keeping gtk12 and glib12 or so).

That is why I'm on the mood of deprecating gnome1 related (gtkmm12 in 
fact concerning the commit you replied) that are said abandon by their 
upstream and (un)maintained by ports at . With a 1 month deprecation period 
everyone interested has the time to save them.

Bapt