Good work Joel, I vote for B Le 11 déc. 2012 15:57, "Joël Grand-Guillaume" < joel.grandguilla...@camptocamp.com> a écrit :
> 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 <o...@openerp.com> 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@lists.launchpad.net > 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.grandguilla...@camptocamp.com > > > _______________________________________________ > 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 > >
_______________________________________________ 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
