From owner-freebsd-stable@FreeBSD.ORG Sun Mar 23 18:41:34 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3650397 for ; Sun, 23 Mar 2014 18:41:34 +0000 (UTC) Received: from a0i55.smtpcorp.com (a0i55.smtpcorp.com [64.131.95.140]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 84317839 for ; Sun, 23 Mar 2014 18:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpcorp.com; s=a0_1; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=cDGgi6MXTY4TzavwDo8bYT7udSHl0Kv9NTr6XU6/BR4=; b=X1Mc7VRfafVxcQhdV/B2ED/oYv4fA5cvVc0CuOVVWyMeTuu0farnSsHxUIvfKvy2QtTLfJX1RI19Dsj1rJC+dQ1vPzkzKHY+/lDXorm03yg/0xnI3vHOWI7rpiUnX92JVkCV4R2qU65j+wkhyadVt//XZew+BOXanMfMJENUBuY=; From: Daniel Corbe To: Jim Ohlstein Subject: Re: reason 23 why we've moved to linux References: <532EDDD0.80700@ohlste.in> <20140323153843.GA16935@lonesome.com> <532F1C48.7080003@ohlste.in> Date: Sun, 23 Mar 2014 14:41:26 -0400 In-Reply-To: <532F1C48.7080003@ohlste.in> (Jim Ohlstein's message of "Sun, 23 Mar 2014 13:39:20 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-Smtpcorp-Track: 446845312.1.56601861 Cc: Randy Bush , Mark Linimon , freebsd-stable stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 18:41:34 -0000 Jim Ohlstein writes: > Hello Mark, > > On 3/23/14, 11:38 AM, Mark Linimon wrote: >> On Sun, Mar 23, 2014 at 09:12:48AM -0400, Jim Ohlstein wrote: >>> last I checked there were over 1500 active ports related PR's alone. >> >> Current count is 1851. See http://portsmon.freebsd.org/portsoverall.py . >> >> The whole list is at: >> >> http://portsmon.freebsd.org/portsprsbyexplanation.py?explanation=existing&sortby=prnumber&reverse . >> >> I did a little rough data reduction for curiosity about changes related >> to "new infra": >> >> % grep -i clang foo | wc -l >> 32 >> % grep -i stage foo | wc -l >> 37 >> % grep -i staging foo | wc -l >> 31 >> % grep -i options foo | wc -l >> 31 >> % grep -i cflags foo | wc -l >> 5 >> % grep USE_ foo | wc -l >> 22 >> % grep WITH_ foo | wc -l >> 19 >> >> as opposed to: >> >> % grep -i update foo | wc -l >> 280 >> >> NB: I didn't check for overlaps. >> >> I was expected to see more "new infra" changes than 200. >> >> I will note that about a third of the PRs are from the last 3 months. >> I no longer have an insight into how fast PRs are turned over but it >> is quite brisk. >> >> mcl >> > > Thanks for your response. I don't think that tells the whole story. > > How many PR's contain "broken" or "broken on 10" or "break" or "build" > or similar? Another few I'm sure. Updates are important too. Many of > us look forward to new features not to mention important security > fixes. The only ones which may not be "urgent" or "important" are the > new port proposals of which I counted 181. (I have a few in there and > I am waiting patiently. I spent quite a few hours working on a port of > MonetDB which sits there untaken. Maybe it sucks but I'd like > feedback/help if needed. I have others for which I directly approached > a committer whom I like and respect since he maintains similar ports, > and was told he's too busy.) > > I'm not trying to make this more a bitch-fest than it is, but I'll > point out the obvious that if a third of PR's are from the last three > months, that means two thirds are older than three months! I don't > find that to be "quite brisk". If the ratio were reversed it I might > be inclined to agree. > > My point however, perhaps was missed. While I did squawk that the new > pkg system is in a state of flux and therefore not appropriate for > sole use on 10, I was separately mentioning the glacial pace at which > ports related PR's get looked at, taken, and committed. There is no > obvious triage system. It's simply if someone is "interested" they > take the PR. If no one is interested, it sits. Imagine if a hospital > emergency department functioned that way. A gunshot wound might sit in > the waiting room because seeing a case of strep throat would be less > work, or a laceration needing sutures might be more fun. And one case > of strep throat might sit six hours while another waited only 30 > minutes because it was up to the doctors and nurses to decide who they > wanted to see and when, not based on any system of necessity, urgency > or how long a problem has been waiting. > > In the current system, if there is a maintainer, s/he may not answer a > PR for months, even if that person is a FreeBSD committer. If ports > don't build, that *is* a big issue because pretty much everyone uses > them. With two thirds of ports related PR's over three months old, > updating your system is a crapshoot at best. How many of these PRs contain remotely exploitable security vulnerabilities? Of which, how many of these ports do you use on a regular basis? You like to talk about "triage" like the very existence of a bug in the ports tree is a show stopper. To use your example, context actually means a great deal in an emergency room. You would treat that gunshot wound victim before you would treat the 1500 other patients in your waiting room with self-inflicted bruises sprains and muscle pulls. There's a finite amount of people available to respond to PRs. They do a pretty good job of maintaining the ports that are most often used. It's been almost a decade since I've had a FreeBSD box fall victim to a remote exploit. By contrast, I constantly struggle to keep the vendor-supplied linux boxes on my network from being broken into. And if you're really so worried about corner cases, perhaps a more pro-active approach to security is required. After all, it really isn't that much more work to maintain a software package from source than it is to constantly scan and run binary upgrades. -Daniel