From owner-cvs-ports@FreeBSD.ORG Tue Apr 10 15:14:25 2012 Return-Path: Delivered-To: cvs-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0597C106566B; Tue, 10 Apr 2012 15:14:25 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6C76A8FC0A; Tue, 10 Apr 2012 15:14:24 +0000 (UTC) Received: by iahk25 with SMTP id k25so10051137iah.13 for ; Tue, 10 Apr 2012 08:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0iHhEGegmuLnuboVH9hIbGqQa1VtHKNHIBC5goUxXmM=; b=oR+nncxOkErDnHQ64JvNfohnXZS479stB3uaJ5RXhhiSp2hliFJkj+MKkwvamKmJaB A48KLKYYVvHR/U/g+OPofJFvOJ5Fi+AJzyrjO8xLXZudANQ+5m3qsgZjSTD+ZUfa2CBF Ay+JRm1VaJOnDAaB+jMtC3aTKyt9D3bCJpW3OuFSUXAa8w4kaihbYm9q1Ra+3cu5BRN4 HU8t58CNBZ5j+PjUTkBZfqW/p7beKvIAivvDzvTuFncKXTzakf5JBuP44HCxxkPnC8fH UGgmnOkopr64UR73OPCI5Pn+ORb+jZjoIEDU/2JwcOmT6m2YBYyMXJAYfCujNKZEMw7l ovRQ== MIME-Version: 1.0 Received: by 10.50.46.167 with SMTP id w7mr2729260igm.73.1334070863614; Tue, 10 Apr 2012 08:14:23 -0700 (PDT) Received: by 10.231.183.203 with HTTP; Tue, 10 Apr 2012 08:14:23 -0700 (PDT) In-Reply-To: <20120410144741.GC73185@gahrfit.gahr.ch> References: <201204092351.q39Npi6F025202@repoman.freebsd.org> <20120410091537.GK98668@gahrfit.gahr.ch> <20120410114537.GL17460@culot.org> <20120410115630.GB2456@lonesome.com> <20120410124449.GB73185@gahrfit.gahr.ch> <20120410144741.GC73185@gahrfit.gahr.ch> Date: Tue, 10 Apr 2012 12:14:23 -0300 Message-ID: From: Marcelo Araujo To: gahr@freebsd.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: bapt@freebsd.org, ports-committers@freebsd.org, ports@freebsd.org, Frederic Culot , cvs-ports@freebsd.org, Mark Linimon Subject: Re: cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-clx-sbcl Makefile ports/palm/coldsync ... X-BeenThere: cvs-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: CVS commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Apr 2012 15:14:25 -0000 2012/4/10 Pietro Cerutti > On 2012-Apr-10, 11:20, Marcelo Araujo wrote: > > 2012/4/10 Pietro Cerutti > > > > > > > > > I might agree on that. But how is a DEPRECATED port better than a > BROKEN > > > one in this regard? > > > > > > > > In my point of view, no make sense have a bunch of ports that actually > > doesn't works or because there is a fetch problem or even it is set as > > BROKEN. Who never was upset when need and find a port but it is BROKEN > for > > some reason, In my view, have a port BROKEN or haven't it, is the same. > Of > > course, I mean when a port is BROKEN for all plataforms as well as for > all > > FreeBSD version. > > I agree on that. > > > > > I believe set it as DEPRECATED is a good way to make the maintainer tak= e > > attention to fix it soon as possible, due he has put effort to insert > this > > software on the ports tree in the past. > > What about submitting a PR, as we usually do for anything else? If it's > ok to wait 15 days (maintainer timeout) to commit an update to a port > that brings in important features, it is even more so to wait to > deprecate one. > That is a very good point, if someone send a PR, nobody need to make it DEPRECATED, but unfortunately, sometimes it doesn=92t happens. And as I can see, almost all ports that switch from BROKEN to DEPRECATED, is because no one send a PR. > > > In case that has any issue related with the ports framework that make t= he > > ports be broken, he can ping any developer to give him more time to fix > or > > even rollback the DEPRECATED commit with a proper message on the commit= 's > > log. > > This is awkward. We're not supposed to spend our time rolling back > unwanted commits. We're supposed to make sure that a commit made to > someone else's port is wanted in the first place. > I agree with you, maybe there is another better way. > > > It also will let us know, what's happen with that port and maybe someon= e > > else could give a hand to help the maintainer to fix it. > > Well, as I see it, marking a port as DEPRECATED is kind of a final > decision. I.e., I'll start to look at alternatives and forget about it. > If you mark a port as DEPRECATED and 12 hours later I back off your > chance with a comment "I'm working on it", a really unconsistent and > confused message will pass. > Here depends! Usually when I need a port that is set as DEPRECATED, first I take a look why it is set like this, and then, I start to looking for an alternative in case I can=92t fix that port or it is really obsolete becaus= e the software is dead for some reason. Best Regards, --=20 Marcelo Araujo araujo@FreeBSD.org