On 1/22/07, Jeff Kowalczyk <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Ledger-smb-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
