[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is LSMB really suitable for the public?
- Subject: Re: Is LSMB really suitable for the public?
- From: "Shell (Shelwyn Becker)" <..hidden..>
- Date: Tue, 24 Apr 2007 13:18:18 -0400
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!
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.
> > 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.
> Ledger-smb-users mailing list