Heavy I/O blocks FreeBSD box for several seconds

[Adrian Chadd]

(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.

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