From owner-freebsd-current@FreeBSD.ORG Thu Jan 10 00:35:25 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 486C516A468 for ; Thu, 10 Jan 2008 00:35:25 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 260D513C448 for ; Thu, 10 Jan 2008 00:35:25 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id C77968C12A; Wed, 9 Jan 2008 18:35:24 -0600 (CST) Date: Wed, 9 Jan 2008 18:35:24 -0600 To: Dominic Fandrey Message-ID: <20080110003524.GB5188@soaustin.net> References: <478556AD.6090400@bsdforen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478556AD.6090400@bsdforen.de> User-Agent: Mutt/1.5.13 (2006-08-11) From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Thu, 10 Jan 2008 00:55:36 +0000 Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD's problems as seen by the BSDForen.de community X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2008 00:35:25 -0000 I appreciate the fact that you took the time to write this post and raise serious issues in a non-confrontational manner. On Thu, Jan 10, 2008 at 12:20:13AM +0100, Dominic Fandrey wrote: > Even minimal I/O load on a hard disk suffices to lock up whole systems. > Posts on the mailinglists current and stable have often been answered > with denial or have simply been ignored. The responses on the mailing lists can indeed vary in quality. My own experience is that many of the key FreeBSD developers respond fairly well -- when they've got time to do so. Some exceptions exist. But I don't think any one person is working on amd64 to the exclusion of i386. Perhaps that is what it would take. Other than trying to identify individuals whose responses are doing more harm than good, I don't have any suggestions here. > What we think might be a solution to the regression problem, would be > the establishing of a Regressions Team, similar to other teams like the > Security Team. Unfortunately it requires volunteers to constitute such a thing. I've been trying to come up with ideas on how to get more people involved in what we would consider 'maintainence' activities, but I've yet to make an impact. A few people have expressed interest in helping to go through the PR backlog, but the big shortage is committers who are willing to work with them on such unglamorous tasks. (I am working on a proposal to at least make it less frustrating to do so, but I don't want to tie that into this thread.) Having said that, I would join such a team and try to work with it. > PRs remain unanswered or the reporters are told that the regressions > they report do not exist. We clearly have a disconnect on PRs. More come in than we have any way to handle. This is clearly most distressing when the PRs contain patches and/or test cases. Again, I'm open to ideas on how to set up something where more people can participate. I've tried to flag certain PRs with '(regression)', fwiw, which is necessary but clearly insufficient. > To solve the performance problems it appears to us, that a guide to > tracking performance problems or a performance test suite is required. I think that's 2 separate issues. I had not thought much about trying to categorize certain PRs as 'performance' but it really does make sense. I will try to work on this issue. There is actually work on performance tests, but it goes on behind the scenes and is not publicized. (The jump in performance for most workloads on i386-7 is due to the efforts of many individuals who have been relentlessly testing MySQL, Postgres, Bind, and other real-world workloads since the 7 branch was created. Kris, the other respondent in this thread, is one of the people doing a great deal of work on this.) Some of this is documented at http://wiki.freebsd.org/Performance. If there's more specific information that needs to be added there, let me know off-list. There is also the work at http://wiki.freebsd.org/PerformanceTracker, which I do not know the state of. This sounds encouraging. FreeBSD is mostly driven by individual efforts (we are, however, seeing more interest from corporations, some of whom see network performance as a key issue). To some extent it's more "interesting" to do new work than do maintainance work; this is a classical software engineering problem. Again, I'm completely open to suggestions on how to get more people interested in working in this area. mcl