From owner-freebsd-current@FreeBSD.ORG Mon Jul 11 20:33:45 2011 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 11C251065673; Mon, 11 Jul 2011 20:33:45 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id C7BF18FC08; Mon, 11 Jul 2011 20:33:44 +0000 (UTC) Received: by mail-pv0-f182.google.com with SMTP id 11so4131929pvg.13 for ; Mon, 11 Jul 2011 13:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mq7Mrsqv9qxK21E7XSuDNvD3yGUqI9tFAUpyr4uVwaM=; b=tlhim085MzZk+lROy+yRx5jfIwY3SGsCOVX1o6lf9pOfA9LJYloQPw4PkcBtbA5m1Q JsQtTeJt5r+WOsGjfsr+ADYAl/dIWyMGk4RPxQ/8MtBohm2HR9vBcQ2Q0ym66V0MXH34 PIp9WtHJvCa/fgP0OfxhYO4M27UHd9o+9bk4I= MIME-Version: 1.0 Received: by 10.68.48.68 with SMTP id j4mr7029305pbn.407.1310416424624; Mon, 11 Jul 2011 13:33:44 -0700 (PDT) Received: by 10.68.49.42 with HTTP; Mon, 11 Jul 2011 13:33:44 -0700 (PDT) In-Reply-To: References: <4E1421D9.7080808@zedat.fu-berlin.de> <4E147F54.40908@zedat.fu-berlin.de> <20110706162811.GA68436@troutmask.apl.washington.edu> <20110706193636.GA69550@troutmask.apl.washington.edu> <4E14CCE5.4050906@zedat.fu-berlin.de> <20110707015151.GB71966@troutmask.apl.washington.edu> Date: Mon, 11 Jul 2011 16:33:44 -0400 Message-ID: From: Arnaud Lacombe To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Current , "Hartmann, O." , arrowdodger <6yearold@gmail.com>, Steve Kargl , freebsd-questions@freebsd.org Subject: Re: Heavy I/O blocks FreeBSD box for several seconds 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: Mon, 11 Jul 2011 20:33:45 -0000 Hi, On Thu, Jul 7, 2011 at 7:45 PM, Adrian Chadd wrote: > (OT, yes, but I'd like to take a stab at explaining "why" these things > fall to the wayside..) > > On 7 July 2011 12:08, Arnaud Lacombe wrote: > >> What would be the point to even start looking at an issue? You guys >> (by "you", I mean "official" committers on public list) don't care > > When someone who has an active interest takes ownership of the problem. > >> about people providing patches, might it be for trivial, obvious, >> fixes. I'm not even talking about complex patches ... When you >> eventually ends up providing a patch, you ends up being slammed a door >> at by maintainers asserting their code is perfect, until logic and >> user complaints prove them wrong. >> >> That said, this comment is off-topic, but I will certainly re-state >> this next month when I'll be ping'ing trivial patches. > > The problem is that someone doesn't own the problem. > > If I commit someone's fix to the tree without really understanding > what's going on, I take ownership of that change and any > issues/breakages/changes that it creates. > > The people responsible for these areas are likely very busy with other > things. It's not that they don't want to help! It's much more likely > that they don't have the time. > > Trivial patches aren't always so trivial. You can change the behaviour > of something subtle which works great for you and not for others. This > is very likely what's going on with IO/CPU scheduling. It's a tricky > area. A simple fix isn't always as simple. > > So if there's a diagnosed problem, with reproducable test cases and > some patches which fix it, I suggest doing something like the > following: > > * create a webpage, even if it's a wiki somewhere (even > wiki.freebsd.org if you ask someone nicely) > * dump all the information you can in there. Having stuff in emails is > great - but it's only really helpful for tracking the 'flow' of a > discussion. Having a summarised analysis of all of that on a webpage > is much more helpful. > * Add the patches there. > * Encourage people who aren't in your immediate community to try them > too - to try and find if your changes mess up other configurations > somehow. > * Be persistent trying to get your changes in. If you've done the > background research, done some wide-spread testing and show you've not > caused any obvious regressions, you're much more likely to get your > changes in. > For the record, I would like to see enforced public review for _every_ patch *before* it is checked in, as a strong rule. gcc system is particularly interesting. But it is not likely to happen in FreeBSD where FreeBSD committers are clearly more free than other at checking-in un-publicly-reviewed stuff (especially _bad_ stuff). This would of course apply even to long-time committers, no matter how it hurt their ego (which I definitively do not care about). - Arnaud > With all of that done, you can likely find a committer who will help > you get your fixes into the tree. > > Please just try not to interpret a lack of response as a lack of > interest. There's only so much time in the day and committers tend to > be a busy bunch, with day jobs that may in no way reflect their > FreeBSD interests. > > Finally, if people do enough of the above and begin to take ownership > of parts of the tree, you'll find someone will likely sponsor you for > a commit bit. > > HTH, > > > Adrian >