Date: Wed, 7 Sep 2011 08:33:22 +0200 From: Erwin Lansing <erwin@FreeBSD.org> To: Stanislav Sedov <stas@FreeBSD.org> Cc: ports@FreeBSD.org, Mark Linimon <linimon@lonesome.com>, "Julian H. Stacey" <jhs@berklix.com>, portmgr@FreeBSD.org Subject: Re: sysutils/cfs Message-ID: <2E6619D2-634B-46CA-82F1-EBEA3DB593E9@FreeBSD.org> In-Reply-To: <20110906233004.f0a93ac6.stas@FreeBSD.org> References: <20110904231821.GC22986@lonesome.com> <201109051005.p85A5ZvN005263@fire.js.berklix.net> <20110906233004.f0a93ac6.stas@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 7, 2011, at 8:30 AM, Stanislav Sedov wrote: > On Mon, 05 Sep 2011 12:05:35 +0200 > "Julian H. Stacey" <jhs@berklix.com> mentioned: >=20 >> Mark Linimon wrote: >>> On Sun, Sep 04, 2011 at 10:32:30PM +0200, Julian H. Stacey wrote: >>>> It is not responsible to threaten to remove ports without warning >>>> between releases for non urgent reasons. >>>=20 >>> portmgr has no such policy. >>>=20 >>> Ports get deleted all the time due to various issues. I prefer to = see >>> a 1- or 2-month warning via EXPIRATION_DATE, but that's my personal >>> preference, not a written policy. >>>=20 >>> mcl >>=20 >> Drive by ports shootings are becoming too frequent, & will get >> FreeBSD a bad name as immature & poorly managed >> A solution: Ensure a policy of expiry dates expire a release after >> a warning is given in a previous releases (except in emergency). >>=20 >=20 > I second this opinion. > We might have not needed the policy a while ago when such deprecations > were rare. Given that we gained several people working actively > on this I'd like to see some policy regarding deprecation as well. > I saw several occasions when ports were deprecated for no apparent > reason, so I can understand Julian and other people dissatisfaction > with this. >=20 > What about requiring that the ports deprecated should be either broken > or have known published vulnerabilties for a long period of > time (say 6 months) for the start? Personally, I'd also love to see > people deprecating ports provide a clear reasoning for deprecation in > the commit message (not just "deprecated some old ports" etc), so one > won't need to guess if he would like to fix/resurrect the port in the > feature? Portmgr is aware of the current discussion and will handle it in due = time. Thank you for bringing it to our attention. -erwin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E6619D2-634B-46CA-82F1-EBEA3DB593E9>