koha-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Koha-devel] Error following update


From: Pat Eyler
Subject: Re: [Koha-devel] Error following update
Date: Thu Dec 11 08:33:00 2003

On Thu, 11 Dec 2003, paul POULAIN wrote:

> MJ Ray a ?crit :
>
> > On 2003-12-11 13:04:02 +0000 paul POULAIN <address@hidden> 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
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/koha-devel
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]