From owner-cvs-ports@FreeBSD.ORG Wed Aug 3 16:26:20 2011 Return-Path: Delivered-To: cvs-ports@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 1033) id 4EAFA106566C; Wed, 3 Aug 2011 16:26:20 +0000 (UTC) Date: Wed, 3 Aug 2011 16:26:20 +0000 From: Alexey Dokuchaev To: Baptiste Daroussin Message-ID: <20110803162620.GA29675@FreeBSD.org> References: <201108011706.p71H6a0p020907@repoman.freebsd.org> <20110802004928.GA41005@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i 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: Wed, 03 Aug 2011 16:26:20 -0000 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