[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 Oct 18, 2016 02:57, "David G" <..hidden..> wrote:
>
> Hi Erik,
>
>
> On 18/10/16 05:29, Erik Huelsmann wrote:
>>
>>
>>
>> On Mon, Oct 17, 2016 at 8:51 PM, Yves Lavoie <..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 likelihood of it being a blocking issue, should be relatively low.

Ok. I talked to chris about it too and I'm convinced we should indeed do this. There's one thing though: we need to decide how to plug in the required migration later.

What I mean is: I don't think our current approach in sql/changes/ is well suited for data migrations: we're bound to make mistakes and while the schema changes can normally be stacked to get to the desired end state, with data migrations it may not be desirable to stack the scripts. Instead, I'd expect us to want to fix the original script for any further migrations and maybe run a different script to fix existing migrations....

Our sql/changes/ approach basically runs every script it encounters in the order specified....

Let's go over the scenarios for applying fixes to our migration scripts and once we have defined how to handle that, merge to matter and start working on the migration.

So, how do you look at this problem?

> 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 and we can work out ways of migrating data transaction by transaction.
> This should
> spread the burden over a period of time
> 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
>
> Regards
>
> David G
>>
>>
>> Regards,
>>
>>
>> Erik.
>>  
>>>
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>>> Comments?
>>
>>
>>
>> --
>> Bye,
>>
>> Erik.
>>
>> http://efficito.com -- Hosted accounting and ERP.
>> Robust and Flexible. No vendor lock-in.
>>
>>
>> ------------------------------------------------------------------------------ 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 ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>
>
>
> ------------------------------------------------------------------------------
> 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
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>

------------------------------------------------------------------------------
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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel