From owner-freebsd-ports@freebsd.org Wed Jun 29 11:15:54 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEECBB8559B for ; Wed, 29 Jun 2016 11:15:54 +0000 (UTC) (envelope-from michelle@sorbs.net) Received: from hades.sorbs.net (mail.sorbs.net [67.231.146.200]) by mx1.freebsd.org (Postfix) with ESMTP id C70D923FE for ; Wed, 29 Jun 2016 11:15:54 +0000 (UTC) (envelope-from michelle@sorbs.net) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from isux.com (firewall.isux.com [213.165.190.213]) by hades.sorbs.net (Oracle Communications Messaging Server 7.0.5.29.0 64bit (built Jul 9 2013)) with ESMTPSA id <0O9J008GU6AO9I00@hades.sorbs.net> for freebsd-ports@freebsd.org; Wed, 29 Jun 2016 04:23:14 -0700 (PDT) Subject: Re: blanket portmgr approval vs. non-fixing changes To: Matthias Andree Cc: freebsd-ports@freebsd.org References: <201606272021.u5RKLVhQ057899@slippy.cwsent.com> <20160628091709.pbvq7lekss2ql2en@ivaldir.etoilebsd.net> <5772E90C.6020908@gmx.de> <20160628213341.vvtobzbvxabphsqc@ivaldir.etoilebsd.net> From: Michelle Sullivan Message-id: <5773ADE0.7060204@sorbs.net> Date: Wed, 29 Jun 2016 13:15:44 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 In-reply-to: <20160628213341.vvtobzbvxabphsqc@ivaldir.etoilebsd.net> X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 11:15:55 -0000 Baptiste Daroussin wrote: > On Tue, Jun 28, 2016 at 11:15:56PM +0200, Matthias Andree wrote: >> >> And I do think we should, opposite to what you are proposing, make the >> committer spend extra time for high-profile ports that entail sweeping >> changes to chase down the breaking change to, say, a library port. >> > I might have been not explicit enough, of course any changes should be tested, > and of course high profile ports breaking means special attention and prevent > the sweeping change to actually happen. > Sorry I think you're wrong at this point. Define "high profile" ... Some library port that other obscure ports are dependent on..? What say postgresql94-client or perhaps p5-Bucardo... something that only a few ports (if any) rely on, yet would be a massive problem for a lot of production servers/services if they were suddenly and quietly broken... It's an all or nothing thing, you either ensure your sweeping changes don't break anything, or don't care about anything and just put out an announcement that you made the change. Selecting some random list of what you consider should not be broken (or should be fixed first) based on some random list of what you think is important is a short sighted and unprofessional methodology as it creates more uncertainty and confusion.. My opinion, feel free to ignore as usual. -- Michelle Sullivan http://www.mhix.org/