[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: From live discussion with David Godfrey: Merge MC branch to master?

On 2016-10-17 17:52, David G wrote:
> Hi Erik,
> On 18/10/16 05:29, Erik Huelsmann wrote:
>> On Mon, Oct 17, 2016 at 8:51 PM, Yves Lavoie <..hidden..
>> <mailto:..hidden..>> wrote:
>>     Hi,
>>     I'm in favor of this.
>>     1- The MC should be part of LedgerSMB, not something we promote
>>     only on a need basis.
>>     2- It would get pulled in the distribution stream, contributing to
>>     marketing of our work. Having apt for the standard and GitHub for
>>     MC isn't appealing to users.
>>     3- We are very few, so removing burdens and freeing time to
>>     develop quicker should be the goal every time.
>> It's great to see that is isn't meeting much resistence. However, what
>> about the (for now) missing data migration? It could end up being a
>> blocking problem to release 1.6. Do you see that as (accepted)
>> collateral damage?
> As you mentioned, I feel that if we merge Multi Currency (MC) branch
> early rather than late in the 1.6 lifecycle the burden, and likely hood
> of it being a blocking issue, should be relatively low.
> We already discussed the following benefits.
>   * There are currently a relatively small number of systems (and likely
>     a small to moderate number of transactions) that will be effected by
>     migration issues.
>   * There will be an increasing number of systems and transactions that
>     will be effected the longer we wait.
>   * If we start any sort of marketing push, the number of effected
>     systems will hopefully grow exponentially
>   * Merging early allows all of the changes to receive much desired
>     exposure to both real world and contrived testing over a long period
>     of time.
>   * Most (probably all) devs will be able to continue with development
>     and testing without needing to deal with migration of data on day one.
>     This is due to the fact that migration will only be needed for
>     specific FX transactions
>   * If we ensure that affected (un-handled) FX transactions found during
>     a DB upgrade throw as errors and block the upgrade, the dev can
>     discuss on #ledgersmb
>     <https://riot.im/app/#/room/#ledgersmb:matrix.org> and we can work
>     out ways of migrating data transaction by transaction.
>     This should
>       o spread the burden over a period of time
>       o Allow us to handle actual scenarios, rather than trying to
>         predict *every* scenario
> If on the other hand we wait until later in the 1.6 life-cycle, we have
> a requirement for
>   * additional burden on the dev's (primarily Erik) to maintain the
>     merge synchronization of the MC branch
>   * a concentrated burst of testing and validation when the merge happens
>   * a need to rapidly resolve the migration issue rather than doing so
>     over a longer period of time

>>>     Two weeks ago, when he was in Europe, David sat down with me to
>>>     discuss a number of items. Some of those will come later. There
>>>     was one major issue we discussed though and I want to bring our
>>>     proposal forward here.
>>>     David put forward that having the MC (multi-currency) branch
>>>     merged to master gets a maintenance burden off my shoulders
>>>     (which it indeed will). In addition to that, merging to master
>>>     early provides for a (hopefully) long enough period to shake out
>>>     any of the problems that it may cause.
>>>     Additionally, his idea is that if this code is on master, it
>>>     becomes our collective problem to create a data migration
>>>     strategy to MC, whereas currently it's probably mostly my problem...
>>>     While I'm not very much in favor of throwing up roadblocks for
>>>     releases, even if they're far in the future. However, I must
>>>     admit that if there are others in favor of moving MC to master so
>>>     we have it for 1.6, getting rid of the maintenance burden
>>>     (however small) does seem attractive.

I thought that I would put a bit of what my thoughts on this are.

I do very few transactions during a month.  I very rarely will be doing
multiple ones which will have foreign exchange on them, so figured I had
no real reason for using the MC branch myself.

On a recent transaction which I completed, I found that I was having
different exchange rates being expressed in different places, on the
same day (on the same transaction) which meant that even though the
transaction all took place on the same day (and pretty close to at the
same time at all locations) I ended up where I was using multiple
exchange rates on the same day.

This is *not* allowed in the non MC branch.  So you either need to
"unify" your rates, or you need to fudge your dates.

Neither of which really express reality.  Which means that while the
books might "work" (and you can make a note to explain why they are
recorded as such) they are not self evident why they might be
technically incorrect.

I personally feel that it probably is rare for any business to strictly
do business in a single currency.

An issue I "discovered" while I was working on this, was the presence of
fractional cent values being stored (and displayed) in foreign exchange
transactions.  When I looked at the github issues, there was an open
issue expressing the exact same experience.

The question as to *when* would be the best time to merge the MC
branch(s) with the "master" of the version I'm not sure when is the best
time.  I would say "sooner is preferable" personally, but we are
currently developing on 3 different version 1.4 (I understand at this
point pretty much bug fixes) 1.5 (currently as a RC (unless I missed
something)) and 1.6 (in very early development, not quite sure what to
call it).  I have seen evidence of development back to 1.3, and possibly
even 1.2 in recent months, but my understanding about that is it is
being done because of some client of either Chris, or Erik still running
those versions, so those releases are based on merging work for specific
clients onto those versions (where doing so is pretty much a bug fix).

My feeling about 1.5 vs. 1.6 is that if doing the transition in 1.5 does
not end up meaning that releasing 1.5 gets pushed back more than a few
days (maybe a week) then I say we could well do it there.  We are so
close to releasing 1.5 as it is, that doing anything which pushes it
back much at all I feel is somewhat problematic in my view.

This is of course just personal thoughts.

Jigme Datse Yli-Rasku

Jigme Datse Yli-Rasku
..hidden.. (Preferred address for new messages)

Jigme Datse Yli-Rasku
PO Box 270
Rossland, BC V0G 1Y0

... This message should be electronically signed, and if the sender ...
... has your public key, may also be encrypted.                     ...
... If you have any questions about this, please email, or call.    ...
...                                                                 ...
... Note, unknown calls likely will go to voicemail.                ...
... Please leave a message if you get voicemail.                    ...

Attachment: signature.asc
Description: OpenPGP digital signature

Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
Ledger-smb-devel mailing list