Re: Is LSMB really suitable for the public?

["Shell (Shelwyn Becker)" <..hidden..>]

Chris Travers:

Just wanted to say that I like what you are doing here. Keep up the good
work! I havn't had much experience with databases, but I know my way
around Linux. Maybe once I learn a little more I can help!

Shell




On Tue, 2007-04-24 at 10:02 -0700, Chris Travers wrote:
> 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
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Ledger-smb-users mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
>