Re: My post-1.4 priorities

Hi Chris,

Thanks for taking the time to draw up your plans. Let me comment on them below.

Once 1.4 gets to rc0 and we branch it off here are my own development priorities. Feedback is appreciated.

Ok. You asked for it :-)

1. I want to move our existing 1.3/1.4 code to PGObject::Simple and PGObject::Simple::Role. This requires minor wrappers and a very little bit of porting for code written in that timeframe.

2. I want to move LedgerSMB::PGNumber and LedgerSMB::PGDate to use PGObject::Types::BigFloat and PGObject::Type::Datetime internally. This would make these modules nearly CPAN-ready and pretty stable.

Well, with the estimated effort of 1 day, I'm not going to spend too much time commenting on these two, other than that I think that if PGObject::Simple is going to be shared with other projects, it's probably going to provide a more stable basis to work off. If that's the case, then I say shared development is shared cost. Good idea.

3. I want to rewrite the financial code (AR/AP transactions, journal entries, payments, invoices, and, optionally reconciliation, though the latter will not require much in the way of rewriting).

Ok. This is a big one. Even though I think it's a great goal to set, if it were up to me, I'd like to split this up in smaller tasks, if possible. One thing that I think is important for the project as a whole is that we can maintain a reasonable level of stability during the entire rewrite -- it helps with the acceptance of the final 1.5 end result. Preferably, we implement measures not only to ensure stability and completeness on an API level, but also start to implement UI tests to ensure the UI works as expected. Even though - as shown in the 1.4 cycle - fixes are often "quickies" when it comes to not-working UI, it's still a major dissatisfier when people start to evaluate a new version.

Also, I've seen that we're now taking quite a long time to do another release again (sure, different priorities, paid work, more work than expected, etc -- all good reasons). I'd like to advocate we don't make any of the above rewrites "define the release" by which I mean, if it hasn't happened, we could go for a smaller step in a release, if we have achieved sufficient other goals. I.e. none of the stated subjects become "release blocker" if not achieved.

We may need to develop a way of working to do these rewrites in a way which doesn't practically make them release blockers: if all refactoring goes on on trunk and it's been done for 50%, then if the current state doesn't work, obviously the refactoring by itself becomes a blocker...

4. I want to start breaking off modules so we can put them in CPAN. The core LedgerSMB.pm logic that we still need should be in LedgerSMB::Request, and we may want to start looking at rewriting the locale and App_State code as well.

Well, I sent a mail about this earlier tonight. As long as LedgerSMB::new() isn't taking too much of our time - other than the recent annoyance - I'd put my effort elsewhere: I mean we have longstanding issues with old code that I'd rather eliminate than revisit code which isn't old code anymore (but probably far from perfect).

5. As a distant priority, I would like to start porting the menu functionality to PostgreSQL extension format, and get the modules to handle that CPAN-ready.

6. Distant even from that I would like to do the same with the Chart of Accounts setup.

I am sure a lot of other stuff and enhancements will be made along the way, but these are the big ticket items. The first two will probably be done in a day. The rest will take some time. Any feedback?

Thanks for your comments. I'd personally really like to get some UI testing and general UI improvements in place -- by which I mean a design which looks more like today's webapplications, ajax request/response like submodule-application pages.

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.