On 02/25/2014 09:59 PM, Raphael Valyi wrote: > > Hello Stefan, sounds like a valid approach too. However I wonder if > that won't be quite much more work. > [...] > Am I missing something? What do you think?
Raphael, for one thing, I don't think these conflicts should be resolved by one party performing the merge without supervision of the community, which will have to be the case when you merge 7 into 8. Instead, when a semi-automated process attempts to merge each atomic OCB-specific change in a separate commit, it will be clear what is merged for what reason and where the conflicts are. The conflicting changes should not be resolved at that point but reverted and then published so that they can be picked up by the community developers to see if they are still valid and in that case adapt and propose again manually. This is much a more transparant process and will lead to higher traceability and quality. Also, we need separate commits for the following reasons: usually, conflicts are caused by competing fixes by the OpenERP developers. When OCB fixes are committed atomically at the 8.0 kick-off, these commits can easily be reverted (which is our standard recipe when such a thing happens). Cheers, Stefan. _______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : openerp-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp