openerp-community team mailing list archive

[Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>]

Dear all,


Some arguments in favor of my suggested idea (called Solution A here):

 * The historic of commit is preserved as we use the https://launchpad.net/bazaar-extractor tool to replay them, but it's boring, I agree.

 * Submitting a patch or making a merge is still possible, but only for "cherry picking" with the bzr "-r" or "-c" option

 * We'll be able to avoid having too much module. The main goal is to "elect" the modules that will be maintain by the whole community starting from v7.0 as on 6.1 we'll still admit more module for historical reason.

 * That is the only way I saw to start with a clean set of modules for version 7.0, well maintained and well reviewed. Otherwise, we'll have "again" all kind of modules in a branch...

What I wanted the most was to avoid porting all v6.1 modules to version 7.0, but rather make a real "community" choice about those who everybody agree to maintain together. Others still find their place in personal/company project / branches.

Now, I can understand your point of view and I'm also in favor of a more easy way to deal with branches, as Bazaar is not the best tools for that (we all agree on that at least). We can take the other solution (called B):

 * Branch the version 6.1 as the root of the 7.0 branch

 * Mark all modules as installable = False, so apps.openerp.com will ignore them. Devs people will know (need to be in the doc by the way) that this module is still not ported to version 7.0.

 * Make a kind of rule that any module that is here (with installable = False) for more than let's say 6-8 month without any news from his maintainer can be remove by community reviewer team from the branch through a merge proposal (using bzr rm).

 * All module that will be ported will need a MP and set the installable = True in it. So it can be reviewed and we'll be able to vote for his inclusion on the next version.

For this last stage, the community reviewer team can refuse the module as they don't want to assume the maintenance of it under a "community responsibility". His owner can then commit it to one of his own repository.

That saying, Who's for which solutions : A or B ?

I'm voting for B (only fool don't change their mind ;) !


Regards,


Joël





Le 11 déc. 2012 à 15:27, Olivier Dony <odo@xxxxxxxxxxx> a écrit :

> On 12/11/2012 03:09 PM, "Lionel Sausin" wrote:
>> Le 11/12/2012 11:25, Joël Grand-Guillaume a écrit :
>>> I started creating the 7.0 series on some of the community projects as we
>>> start migrate some modules. I did it without branching the 6.1 serie and I
>>> associated a brand new branch on them. The goal is here to start including in
>>> the 7.0 serie only the migrated module. This way, everybody will know that
>>> all modules present in a serie is supposed to work on the designed version
>>> (here 7.0). This sounds better to me than having all modules but not migrated.
>> You're losing the bzr history, which obfuscates useful data, disables
>> cross-merges and makes back/forward porting of bug fixes painful.
>> I humbly suggest you branch from 6.1 and mark the modules "installable: False"
>> ? Then mark "installable: True" when the modules are ported to v7.0
> 
> I agree with Lionel, this might create un-necessary problems in bugfix/code management, though I also approve Joel's desire to avoid creating a mess of migrated/non-migrated modules in the same branch.
> 
> The idea of using the installable flag to False sounds good, and we could have OpenERP Apps ignore modules that are not installable - they would be virtually invisible until migrated to the branch's series.
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp

-- 

Joël Grand-Guillaume 
Division Manager
Business Solutions

Camptocamp SA
PSE A, CH-1015 Lausanne
http://openerp.camptocamp.com/

Phone: +41 21 619 10 28
Office: +41 21 619 10 10
Fax: +41 21 619 10 00
Email: joel.grandguillaume@xxxxxxxxxxxxxx