Zbr's days.
November
Sun Mon Tue Wed Thu Fri Sat
       
14
 
2007
Months
Nov

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)