Re: Is LSMB really suitable for the public?

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

We are committed to making LSMB ready for all SMB's.  It is not there
yet.  It requires little technical knowledge  but a willingness to ask
for help, so at the moment it is best suited for the Free/Open Source
Software community.

Secondly *all* of the problems you mention have been the result, not
of enhancements, but of attempts to get the basics (security,
accounting logic, process controls) right.  In my view, these are more
important than simplicity of installation because problems in these
areas will cause more problems for users with less technical knowledge
than those with more.  An easy installation, while certainly
desirable, is more of an enhancement than a functioning security
infrastructure (which, BTW, we still don't have-- we can do
authentication reasonably well, but the SQL-Ledger codebase makes no
real use of any authorization structure).

The codebase we inherited was, politely put, a mess.  It is to be
expected that there will be growing pains and migration from
SQL-Ledger will become harder.  Mr Tangye: I am sure that you have
seen the mess of the db schema, and as we get things right, there will
be (perhaps many) cases where a problem in the upgrade will require
someone who is knowledgeable to resolve.  It is mathematically
impossible to automate in all cases the migration from a schema with
ambiguity problems to one without.

1.2.x is likely to be the hardest release from a QA perspective for a
number of reasons including:

a)  the SQL-Ledger codebase does not handle automated tests well.  And
those automated tests we did write in areas of number rounding and
formatting were failed.  We cannot build tests until the codebase is
in a more stable form.  Manual testing is something that we could use
help with though.

b)  1.2.0 is the beginning of the refactoring.  This means the most
points where things can go wrong.



A few other comments are inline.
<snip>

> Without prattling on about this any further, can I just ask/suggest that
> the developers:
>  1. Stop doing functionality extensions/improvements

Not economically feasible for me, at least.  Or are you offering to
pay my bills for the year or so it is likely to take to fix the
current codebase?

>  2. Get the basics right.

With all due respect, that is what we are working on.

Every one of the problem areas represents a basic problem case in the
SL codebase in areas of security, accounting logic, and both basic and
relational mathematics.  Unfortunately the codebase is such that
nobody fully understands it.

>  3. Set up and adhere to a better more comprehensive system test
> strategy, and stop releasing any further stuff in future until it is
> properly tested.

We have some automated tests for any of our new code.  The old SL code
does not adhere well to such a strategy.  We do what testing we can.
However, our resources are limited and we do rely on help from others.

One point I would note is that every test set we have written has thus
far failed in the old SL codebase.  Issues from number rounding and
formatting onward.  Just yesterday I got a bug report that I thought
was a problem in our code but turned out to be a regression to SL.

> I have held off migration from SL, because this trend of broken releases
> is concerning me, and I am seeing no evidence of any attempt to control
> releases properly. In fact I am seeing too much hackering here.

I would *highly* recommend at least migrating to 1.1.12.  The reason I
say this is that none of the non-auth-bypass security issues I have
sent to Dieter have been resolved, and many of them have been subject
to full disclosure emails on Bugtraq.  You can stay with SL if you
like if:

1)  it is a single-user install or
2)  you have absolute trust in your users' actions not to embezzle
money and pin it on someone else.

I will be posting more detailed recommendations in a separate thread.


> It seems that the developers here suffer the same problem I have seen in
> many software efforts: techos lost in their own world, unable to
> understand that their end user is NOT as cluey as them in software
> matters. Half the time you might as well be speaking Martian.

David:  Please take this as a warning and read the Ubuntu code of
conduct (http://www.ubuntu.com/community/conduct/).

I think we have to get the technological basics right before we can
address the user experience issues.  I know you have taken a look at
the database schema, so you must have *some* idea what is involved,
and in case you have no knowledge of Perl, let me say that the same
sort of structural problems exist in the program logic but are perhaps
worse simply because the perl scripts are longer than the DDL.

Best Wishes,
Chris Travers