openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

By the way

a few more remarks about this branch v7 migration process:

   - at Akretion we introduced the [MIGR] prefix on the commit messages to
   explicit that a commit is dedicated to migrating to the new version of the
   module dependencies (eg OpenRP 7). This is meant to make it easier to track
   the migration and find out what's a fix, a refactoring or an improvement or
   just the migration process; this also facilitates the cherry picking work
   for people backporting features on older branches. Also please don't mix
   migration thing with fixes or general improvements that could be
   backported. Thoughts?
   - an other thing we used to do at Akretion is when migrating a group of
   modules inside a branch, we use to create a branch per module migration in
   order to parallelize things when it's possible (instead of having to
   constantly merge others migration work). At the end of the process, when
   some modules are reaching some maturity for the v7 version, the branches
   are re-merged into the 7 branch serie. An example is what we are doing for
   the migration of the Brazilian localization:
   https://code.launchpad.net/openerp.pt-br-localiz where you can see 3
   branches with the "migr-" prefix.

What do you think?

Regards.

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com





On Tue, Dec 11, 2012 at 12:57 PM, Joël Grand-Guillaume <
joel.grandguillaume@xxxxxxxxxxxxxx> wrote:

> 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
>
>
> _______________________________________________
> 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
>
>