Re: [ledgersmb-devel] What should the process toward merging the MC branch be?

Hi,

Over the past weeks, we (on the ledgersmb chat channel) have been working to complete all open tasks related to the "Phase 1" of Multi Currency support. Additionally, we have been testing the schema migration code with a number of real-life databases and fixing issues.

A number of bugs and other findings have been fixed. Pre-migration versus post-migration trial-balance comparisons have been implemented as migration validations.

After more testing yesterday and today, the following fixes were committed and pushed:

- Fix the default currency (functional currency) correctly showing on invoices

- On invoices, in the Payments section, show both the base currency and the invoice's currency amounts

- Improve the layout of the Subtotal/Tax/Total section on invoices regarding presentation of default and invoice currency amounts

- Make sure the table header and footer on the GL journal entry screen have the same length (= same number of table cells)

- Fix the foreign currency amounts in the credits column on the journal entry screen showing up empty, even if filled in the database

The branch implements new tests unit tests and BDD tests. The branch implements tests for the schema migration code. The branch has undergone manual testing recently (in addition to the manual testing which happened when the code was written originally).

The question now is how to proceed?

Going over this question on the ledgersmb chat channel on Matrix (riot.im), consensus is that the ideally all code being merged is also tested. While the branch does add more tests than are currently on master, it's certain that not all functionalities are currently (extensively) tested. However, consensus has it that keeping the MC work on the branch much longer will mean a counterproductive additional cost to the project: since a lot of the code for which tests will be developed, currently isn't tested on master either and when tests will be developed, bugs are likely to emerge. Any bugs that don't relate to MC will then need to be fixed on master instead of on master-mc and then the changes will need to be integrated with master-mc from there. This procedure is highly likely to produce merge conflicts the resolution of which will mean destabilization risks for the MC branch. (And the above doesn't even consider yet the fact that most of the resources for all of it will have to come from one person...)

The proposal is now to merge the MC branch really soon and from there work to develop a (large) set of new tests on master where the cause of the issues which the tests potentially find, doesn't matter anymore: the fixes need to be implemented on master in any case.

Would anybody be prepared to jump in with manual testing of the branch and the migration code? Should we be merging the branch to master and find testers there? Should we be writing more tests on the branch before merging? If so, how many tests are "good enough" before we can merge? Or should we merge and develop tests on master? (Which we should anyway...)

For anybody interested what it is exactly that I'm writing about, check the comparison between the master and master-mc branches: https://github.com/ledgersmb/LedgerSMB/compare/master...master-mc (statistics: 415 commits; 6417 additions, 3514 deletions, 161 affected files; first commit June 27, 2015; last commit: today.)

Regards,

Bye,

Erik.

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

Robust and Flexible. No vendor lock-in.