Heavy I/O blocks FreeBSD box for several seconds

[Arnaud Lacombe]

Hi,

On Thu, Jul 7, 2011 at 7:45 PM, Adrian Chadd <adrian at freebsd.org> 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 <lacombar at gmail.com> 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
>