Long time no see. It's 11pm here now and I'm still in the office. Just though about why not to post to the blog right before I drive home. Really, why not?
I'm mostly working on new vzctl release lately (you can see the progress in vzctl's git web interface here). The ultimate task is to fix most of bugs opened for vzctl in OpenVZ bugzilla (some are dated back to 2007 -- no, they are not critical or even major, but anyway). So far the list of vzctl bugs yet opened are down to one singe page (i.e. scroll bar has disappeared from the browser window) which is a big improvement.
The process is somewhat slow because of my attitute to fix even minor things thenever I notice them -- known as code refactoring. The simplest example is when you open a C file in vim (or Emacs, whatever) and see that there are spaces instead of tabs. When you notice it, there are three ways to go: (A) leave it as is; (B) fix it in place, keep working on what you've planned, commit; (C) fix it, make a separate commit, then continue working on what you've planned.
Way A is not that bad, actually, it's definitely better than B, because the result of B is a spaghetti of a functional (e.g. a new feature or a bugfix) and non-functional (e.g. whitespace cleanup) changes. Mixing apples and oranges is a bad thing to do: it makes patch review harder, it makes porting between branches harder, and in case you'll want to revert the patch (say because of a bug in new code) you will also revert those cleanups (which are not buggy). So, if you are not a perfectionist, better follow way A but please not B.
Unfortunately I just can't ignore the bad things I see, so I follow the way C. Sometimes this is very annoying, because instead of implementing a new feature you keep refactoring your code for hours, sometimes even days. No, it's not only whitespace cleanups or fixing typos in comments. Sometimes you see that there are a few identical snippets of code and you put that code into a new function. Sometimes you notice that some function arguments are unused (or always the same) and you remove those. Sometimes you just read the code and see there is a bug in it, and you fix it. Oh, the text of error message is not clear enough -- you fix it. The typesetting of a man page is wrong (e.g. bold is used instead of italic for variable argument) -- you fix it. You see that a function is not used outside of the source file -- you make it static and remove its prototype from a header file. You notice a typo in the function name (and of course also in every place that calls it, since otherwise that code won't compile) -- you fix it. A typo in a comment -- fix it! And so on, and so forth...
Every single thing from the above paragraph (and some more) happened to me when I was working on the boot order priority feature (the subject of OpenVZ bug #1300). So I ended up with 22 (twenty two) code commits, from which 3 implement the actual feature, 1 documents it, and the other 18 are all code refactoring, preparation and minor bugfixing.
The way to perfection is never easy. That doesn't mean we shouldn't try.
I'm mostly working on new vzctl release lately (you can see the progress in vzctl's git web interface here). The ultimate task is to fix most of bugs opened for vzctl in OpenVZ bugzilla (some are dated back to 2007 -- no, they are not critical or even major, but anyway). So far the list of vzctl bugs yet opened are down to one singe page (i.e. scroll bar has disappeared from the browser window) which is a big improvement.
The process is somewhat slow because of my attitute to fix even minor things thenever I notice them -- known as code refactoring. The simplest example is when you open a C file in vim (or Emacs, whatever) and see that there are spaces instead of tabs. When you notice it, there are three ways to go: (A) leave it as is; (B) fix it in place, keep working on what you've planned, commit; (C) fix it, make a separate commit, then continue working on what you've planned.
Way A is not that bad, actually, it's definitely better than B, because the result of B is a spaghetti of a functional (e.g. a new feature or a bugfix) and non-functional (e.g. whitespace cleanup) changes. Mixing apples and oranges is a bad thing to do: it makes patch review harder, it makes porting between branches harder, and in case you'll want to revert the patch (say because of a bug in new code) you will also revert those cleanups (which are not buggy). So, if you are not a perfectionist, better follow way A but please not B.
Unfortunately I just can't ignore the bad things I see, so I follow the way C. Sometimes this is very annoying, because instead of implementing a new feature you keep refactoring your code for hours, sometimes even days. No, it's not only whitespace cleanups or fixing typos in comments. Sometimes you see that there are a few identical snippets of code and you put that code into a new function. Sometimes you notice that some function arguments are unused (or always the same) and you remove those. Sometimes you just read the code and see there is a bug in it, and you fix it. Oh, the text of error message is not clear enough -- you fix it. The typesetting of a man page is wrong (e.g. bold is used instead of italic for variable argument) -- you fix it. You see that a function is not used outside of the source file -- you make it static and remove its prototype from a header file. You notice a typo in the function name (and of course also in every place that calls it, since otherwise that code won't compile) -- you fix it. A typo in a comment -- fix it! And so on, and so forth...
Every single thing from the above paragraph (and some more) happened to me when I was working on the boot order priority feature (the subject of OpenVZ bug #1300). So I ended up with 22 (twenty two) code commits, from which 3 implement the actual feature, 1 documents it, and the other 18 are all code refactoring, preparation and minor bugfixing.
The way to perfection is never easy. That doesn't mean we shouldn't try.


Comments
What do you think about that?
Cheers,
Gaston
http://k001.livejournal.com/tag/openvz