On Thu, 11 Dec 2003, paul POULAIN wrote:
MJ Ray a �crit :
On 2003-12-11 13:04:02 +0000 paul POULAIN <paul.poulain@free.fr> wrote:
It was typo error introduced by Slef when fixing bug 662.
OK, sorry. I'm working through 40 screens of likely security problems for bug 662 on my own in my spare time. Occasional typos happen, especially when seeing the same buggy code fragment pasted in the Nth place. Maybe I should be refactoring that when I find it, but that will probably introduce more bugs. Sorry for non-response here yesterday: I'd been out driving through the bad weather.
no prob (except a nice -but cold- sunny here :-) ) & I agree refactoring too much results in more risks than improvements.
One nice thing about proper refactoring (with unit-tests) is that the risk is very low. make a change, test to verify nothing broke, make another change, etc.
slef : could you pls always check that a C4 package compile before commiting it (at least).
This should be a basic rule. anytime we make a code change, we should *at least* use 'perl -c' to make sure we haven't introduced a compile time error. As we build unit tests (see below), running those will provide even more safety.
Can you write me a unit test for this, or point me at the pre-commit unit tests, please? Surely there are other things which I should check, but I won't know until I break.
Currently there are very few tests (unit or otherwise) within Koha. This is a major shortcoming. Please, if you're going to fix a bug, or add a feature, take a little bit of extra time and add a test to the existing test harness. If you have a bit of extra time, but aren't up to working on a new feature or a bug fix, write some tests (and/or some docs/comments). It's little things like this that will really pay off.
That's something we lack, for sure... & we always have 2 choices : * improve code stability * improve features. The problem being that users prefer features :-(
I don't think I agree (about the 2 choices, not about user preferences). Not improving the code stability/maintainablity is like going into debt. We will always be incurring some debt as we try to do new things. If we don't pay off what we owe (by refactoring), we *will* become overwhelmed. Another major win is that as the code become more stable and manageable, new features become easier to add (and, more importantly, easier to add without breaking existing code).
For other scripts it's not as important, but breaking a C4 package causes Koha major failure.
CVS users should be used to this?
yes, of course. But it's always boring to see something suddenly badly broken by "compilation error" (not sure "boring" is a good word here. Maybe too much, but i don't know another word :-) ).
While CVS users might be used to it, there is something to say for them not having to see it too often. Yes, we will introduce bugs. Hopefully we won't leave things in flames ... it's almost a shame we can't really run a tinderbox/smoketest environment -pate
-- Paul POULAIN Consultant ind�pendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel