From owner-cvs-ports@FreeBSD.ORG Thu Aug 4 06:14:02 2011 Return-Path: Delivered-To: cvs-ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 017DF106564A; Thu, 4 Aug 2011 06:14:02 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from xiurhn.etoilebsd.net (xiurhn.etoilebsd.net [94.23.37.58]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3128FC13; Thu, 4 Aug 2011 06:14:01 +0000 (UTC) Received: by xiurhn.etoilebsd.net (Postfix, from userid 80) id 9978B7E80D; Thu, 4 Aug 2011 08:14:00 +0200 (CEST) To: Alexey Dokuchaev MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 04 Aug 2011 06:14:00 +0000 From: Baptiste Daroussin In-Reply-To: <20110803162620.GA29675@FreeBSD.org> References: <201108011706.p71H6a0p020907@repoman.freebsd.org> <20110802004928.GA41005@FreeBSD.org> <20110803162620.GA29675@FreeBSD.org> Message-ID: X-Sender: bapt@FreeBSD.org User-Agent: Roundcube Webmail/0.5.3 Cc: cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org, ports-committers@FreeBSD.org Subject: Re: 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 ... X-BeenThere: cvs-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:14:02 -0000 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@. With a 1 month deprecation period everyone interested has the time to save them. Bapt