Re: future of LedgerSMB

["Chris Travers" <..hidden..>]

On 1/22/07, Jeff Kowalczyk <..hidden..> wrote:

> I agree with this, a rewrite with redesign [1] would take way too long for any
> new or SL user to remain interested in SMB.
>
> > Rewriting in Perl gives us the ability to have a useful application
> > while we are working on it.
>
> What about starting by retrofitting tests on the existing application, and
> getting the community involved at the same time?

Because I can guarantee you that we will find too many failed trouble
spots to fix :-)  We have started on this sort of thing.  In 1.2, you
have a build script that allows you to run what tests we do have.
Needless to say, it was a lot of work just to get those tasks to pass
:-) And these were things like number rounding and formatting (which
should be extremely straight-forward).  There are a large number of
other areas that are known to be broken.  In short as long as we are
re-engineering, we can assume that every part is almost good enough,
but our time is better spent on actually getting portions re-written
and having tests written for those sections.

> If perl has something like doctests, and given a thin API around the URL
> passing syntax, you might be able to attract new users to help:
>
> - Find out what works, prevent regressions
> - Tests help design the API you eventually want SMB to expose
> - Document edge cases where SL's data integrity can be corrupted
> - Get non-programming accounting users involved; show how to convert a visible
> URL to a function call syntax, run and write up as doctest.[2]

If the code was of better quality and not known to be broken in so
many points, I would agree with you.  However:

1)  We need to be able to weigh the damage due to breaking people's
custom work with the need to create a solid application.  1.1.7 broke
a few things people might have been doing with 1.1.1 because of
serious security issues.

2)  We are actually looking at moving away from the url-based API
because it is way too cumbersome for this sort of app.  I suppose that
will probably still be supported, but will probably be permanently
deprecated once we have working script hosts and XML interfaces.

> A well-documented procedure for submitting doctest-like test cases would make
> for a good Trac ticket type. Each test case, if accepted and merged, would have
> a name (ticket number) that could follow through subsequent revisions of SMB.
> Submitting users may take on a sense of ownership about their pet test cases.

Agreed.  But I think this should wait until 1.3 is getting closer to release.
> If a test suite can be brought to critical mass to drive the
> rewrite/refactoring process:
>
> - Fix or replace broken modules first
Are any modules *not* broken?

> - Define an API deprecation process (e.g. two timed releases)
When a module is is initially replaced, the API's will be removed.
After that, we have some possible issues.   And you are right-- we
need to define a process for deprication.   I would say at least two
major releases.

> - Update tests' pass-fail assertions for deprecation, breaking or API changes
> - Test migration of schema changes

Agreed.  But again, we aren't even to a point where this makes sense
yet unfortunately.

Best Wishes,
Chris Travers