Community mailing list archives

Re: OCA project: __unported__ folder considered painful

- 03/11/2015 06:10:46
Yes, in git it is uncomfortable to work with files that were both 
renamed and modified.
So moving to _unported_ is not nice indeed.

However you *must not remove* ("git rm") the modules, or else any form 
of merging is going to be hell.
So if you want the modules out of the way you must :
- create a new branch from scratch, instead of forking from vN-1.
- migrate the modules 1 by 1, using "git subtree" to preserve history

But even this way I guess you wouldn't be able to make simple merges 
from v7 to v8.
These *merges are useful*. Not making them means you have to find and 
fix conflicts all on your own every time you need to forward-port 
something, with no tool to help you.
I've just done that last week to port a big refactoring from v7 to v8. 
No merge was ever done between the branches, so I had to cherry pick all 
the changes - that was *not fun*

Porting to the new API does generate a lot of conflicts, all right, but 
at least git does tell you where the conflicts are and you can focus on 
that. So it's not a reason to not merge the branches.

As to splitting every module to a repo, I still object to it.
OCA projects are supposed to have each a community and a project leader, 
having all the code in one place serves their purpose well.
I find it very practical to be able to "follow" to the projects I'm 
interested on github.

So, my suggestions are:
- quit renaming directories, leave unported modules where they are and 
just set "installable=False"
- help project leaders to organize automatic merge of branches 
v6.1>v7>v8. I'm sure the tools already exist for OCB, we just need 
documentation, help and volunteers.
I for one can volunteer to monitor the automatic merges of a few 
projects (stock-logistic-warehouse, l10n-france, 
stock-logistic-workflow, maybe mrp...)

Le 11/03/2015 08:51, Quentin THEURET a écrit :
> On 11/03/2015 08:27, Alexandre Fayolle wrote:
> > 1. am I the only one to feel the pain of __unported__?
> Sorry, I didn't play a lot with merges of ported/unported modules, so I
> cannot tell you if it's very annoying.
> When the decision of put the unported modules in a __unported__ folder,
> I think community hoped all these modules will be ported into 8.0. But,
> it is not the case…
> I fear that if we remove these modules from the __unported__ folder and
> only let them on the 7.0 branch, we will lost the information that the
> module exists but it is unported to our version.
> > 2. do you think it is worthwhile to have 7.0 -> 8.0 merges for OCA projects?
> If the rewriting of the module is complete, I think it's not very
> worthwhile to have this kind of merges because the diff are too complex.
> > 3. do you have ideas how to tackle the two objectives above (preferably
> > without going through a huge reorganisation of our repositories, cf.
> > note below)?
> Maybe we can only put a file ( ?) for each unported module
> in the __unported__ folder which gie a link to the good branch where the
> module is availalbe. With this idea, we can remove the unported module
> source code, but we keep the information that other modules are
> available in an old branch.
> Regards,
> -- 
> Quentin THEURET
> TeMPO Consulting
> 20, Avenue de la paix
> 67000 Strasbourg
> France
> Tel : 33 (0)3 88 56 82 18
> Fax : 33 (0)9 70 63 35 46
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe: