|
|
About ::
TODO ::
Blog ::
RSS ::
Old blog ::
Projects ::
GIT ::
Gallery ::
Notes
Wed, 14 Nov 2007
Climbing evening.
That was very good training, although quite short - after usual
warming traverses I tried number of starts of various traces
on the negative horizontal slope, where later tried several traces.
I found that besides horizontal slope I can do them pretty
easily already, so I continue to develop power endurance
on the negative slope. I can not say there is a major progress
in that area, but I can complete some startes on the negative
horizontal slope, which I previously could not, so likely there
is some gain in that exercises.
/life :: Link / Comments (0)
Perfect bugs.
A recent thread
started by Natalie Protasevich, who is a kernel bugzilla master now, shows a
number of bugs which were reporeted recently to different kernel subsystems.
Andrew Morton replied marking essentially most of the bugs (if not almost all)
as being not responded by developers at all and some words about decreased kernel
quality. This rised quite heavy (void actually) discussion about how this should be
fixed (not bugs, but 'the process') and so on (I deleted the whole thread after read
about a one quarter of all messages if not less).
There are two interesting moments of fixing bugs, which I want to highlight here.
First, do not even expect someone will look at your bug just because of that. I like
to fix bugs, I really like to do it, but having 'no reply from developers' behind
does not force anyone to start doing so. And that is frustrated, when work is being done,
and done pretty good, but instead kernel leaders say that there was no reply from developers.
This frustration and complete wrongness of such approach was showed in the thread,
and I hope was gotten into account.
Another issue is a bug quality. I have number of friends, who are able to read minds, but
right now they are all on vacations, so it is pretty hard to determine what the bug is
(like 'I used 3 years old kernel and it works bad/crashes/destroy my data/whatever').
Yes, providing a bug is not that trivial and simple, if you want it to be fixed,
please help us to do so, do not throw it and expect things to get changed.
Really perfect bug has a description and a test case. While I wrote this entry
I found how performance regression, reported by Nick Piggin, was analyzed
by David Miller, tested by Nick, problem was found and bug got fixed by Herbert Xu.
Just because it was a good bug report, with tight cooperation with reporter.
If it would not be fixed right now (americans will go to bed soon or should
be there already), I wanted to fix
it myself just because it contain perfect description of the problem
(perfomance degradation using special benchmark tool) and it is possible to
(easily) perform the same tests locally (tool is a tbench benchmark ran over lopback).
And I pretty sure, I even insist, assure and even can prove, that when bug is reported correctly
and there is a way for developers to catch the problem, it will be fixed immediately.
Of course it is not always possible (like when bug is in the driver and only limited
number of people have hardware), but even then reporter should do a bit (just a really
small bit) of work - find a maintainer of the driver (it is easy - check MAINTAINERS
file in the source tree or search for driver name in the mail archives) and kick it.
Provide a lot of info, maybe resend bug report several times (yes, people frequently
forget about such things like fixing own bugs), copy appropriate mail lists.
If you have enough background, start helping developers a little bit more:
like use git-bisect
to find exact commit which caused a regression, if it is recent bug; or add debug
prints to determine where driver stops working; or just run different (as simple as possible)
tests to show exact condition where problem occurs so that developers could
reproduce problem using own setup.
This are really simple things to get bugs fixed, and we do can fix 'the process' without
all those words, just by doing things.
/devel/other :: Link / Comments (0)
|