openerp-community team mailing list archive

[Leonardo Pistone <leonardo.pistone@xxxxxxxxxxxxxx>]

Hi!

I am still convinced it would be somewhat less painful to have 6.1 and
7.0 in github, too.

Existing MPs scare me less, since it's a one-time problem, and it's
easy to spread the work: each person can take care to duplicate their
own MPs to github, so there is no enormous task or management needed.

On the other hand, we will continue to work on 7.0 on a long time, and
having all versions of the module on the same system, especially if
that system is git that handles multiple branches much more easily
that bzr, would make IMO our life much easier.

As an example, I imagine myself a year from now working in a module on
v8, and then backporting the same thing to v7. With two systems, that
will be a pain, whereas with git, a simple checkout/rebase should do
the trick. On the other hand, the few open MPs each one has can be
handled in an afternoon and be dealt with forever.

Whatever decision is taken I'm happy to help.

Thanks to all for the hard work!

On Mon, Jun 23, 2014 at 11:16 AM, Joël Grand-Guillaume
<joel.grandguillaume@xxxxxxxxxxxxxx> wrote:
> Hi,
>
>
> First thank you for your feedback. About the LP -> Github migration. The
> main arguments in favor of keeping v 6.1 and 7.0 on LP and mirror on Github
> is that we do have lot's of reviews in progress. It'll be difficult to
> maintain reviews on LP if the master is Github.
>
> Moreover, the translation process is not clear on github, so we know that on
> LP everything is working fine.
>
> Now, it's a democratic decision, if the majority of your wanna make github
> the main repo for all versions, so be it. I'm only giving my though here.
>
> The responsible for that within the OCA is currently: Guewen Baconnier,
> Alexandre Fayolle, Stefan Rijnhart, Sébastien Beau and I. Share your point
> of view here and they'll make the final decision.
>
> Regards,
>
> Joël
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Jun 23, 2014 at 9:46 AM, Pedro Manuel Baeza Romero
> <pedro.baeza@xxxxxxxxx> wrote:
>>
>> Hi, Guewen, count with me to help in the transition.
>>
>> Regards.
>>
>>
>> 2014-06-21 14:09 GMT+02:00 Bidoul, Stéphane <stephane.bidoul@xxxxxxxxx>:
>>>
>>> Hi,
>>>
>>> Some comments about migration strategy below.
>>>
>>> On Fri, Jun 20, 2014 at 3:08 PM, Guewen Baconnier
>>> <guewen.baconnier@xxxxxxxxxxxxxx> wrote:
>>>>
>>>>
>>>> The decisions discussed so far
>>>> ==============================
>>>>
>>>>  - The branches up to 7.0 will stay on Launchpad
>>>>    Though, they will be mirrored on Github (Github doesn't have readonly
>>>> branches but the committers won't commit on them)
>>>>  - Starting from 8.0, they will be on Github
>>>>  - For the OCA committers and reviewers, it means that we will need to
>>>> review both on Launchpad and Github, but it avoid the need to migrate
>>>> all the pending merge proposals and bug reports
>>>>  - There is no date planned for the creation of the 8.0 branches, sooner
>>>> means more duplication of proposals (and some pain to follow the master
>>>> branch changes, which is still unstable), on the other hand, some people
>>>> already work on modules for v8.0.
>>>>
>>>> Some scripts (fast-import, ...) or ideas have already been published but
>>>> I want to have a reference in this thread, so please share them.
>>>
>>>
>>> I'm one of those who voted to keep 6.1 and 7.0 branches on launchpad.
>>>
>>> I still think we need to keep those branches up-to-date on launchpad to
>>> preserve existing deployments.
>>>
>>> I now believe however that maintenance activities should take place on
>>> github for all branches, while maintaining launchpad as a mirror for 7.0
>>> and 6.1. This should facilitate development while preserving deployments.
>>>
>>> Many of us we will have to maintain 7.0 (and 6.1) installations for
>>> a possibly long period of time, and having everything under the
>>> same VCS (git) will greatly facilitate the management of back and forward
>>> ports of features and corrections.
>>>
>>> The short term drawback I see so far is that we'd need to reapply
>>> current MP's to github as PR's. IMHO this is a small price to pay to reap
>>> larger benefits on the long run.
>>>
>>> What do you think?
>>>
>>> Regarding tooling, I'm experimenting with git-bzr-ng (apt-get
>>> installable).
>>> While I have not done anything fancy nor large scale yet, I could
>>> easily migrate lp:acsone-addons from lp to github and the mirroring
>>> workflow looks quite simple at first glance.
>>>
>>> It looks like this:
>>>
>>> # first create new empty repository on github
>>>
>>> # then clone lp:acsone-addons in a new local git repo
>>> git bzr clone lp:acsone-addons/trunk acsone-addons
>>> # import additional branches from bzr
>>> cd acsone-addons
>>> git bzr import lp:acsone-addons/7.0
>>> git bzr import lp:acsone-addons/6.1
>>> # create a remote named origin, pointing to the github repo
>>> git remote add origin git@xxxxxxxxxx:acsone/acsone-addons.git
>>> # push the 3 branches to github
>>> git push -u origin master
>>> git push -u origin 7.0
>>> git push -u origin 6.1
>>>
>>> That was it and the git history is looking good at first glance.
>>>
>>> Then adding stuff on github and mirroring to launchpad looks like this:
>>>
>>> git checkout master
>>> # ... add and commit README.md and LICENSE
>>> # push to github
>>> git push
>>> # push to bzr
>>> git bzr push
>>>
>>> So if we decide to keep launchpad as a mirror,
>>> a nightly script could work like this:
>>> - git fetch
>>> - for each branch:
>>> -    git checkout $branch
>>> -    git bzr push
>>>
>>> git-bzr maintains the mapping between git and bzr branches in
>>> .git/config.
>>>
>>> In the end if the decision is to keep lp as the master for 7.0 and 6.1,
>>> the same tool could work too (git bzr sync, then git push for such
>>> branches).
>>>
>>> I'll dig deeper next week and see what an automated script would look
>>> like in practice.
>>>
>>>> Volunteers
>>>> ==========
>>>>
>>>> The transition will probably need a lot of boring and tedious - more or
>>>> less manual - work. More work than can be done by a single person, so my
>>>> first concern is to compile a list of the heroes who will take part and
>>>> will accept to share the tasks.
>>>>
>>>> Please announce you! and inform if you have superpowers or special
>>>> abilities that could help (git-fu, launchpad api, github api, CI, ...)
>>>
>>>
>>> I'm in. No particular superpowers, I'm afraid :)
>>> For instance, I can help putting the mirroring scripts in place
>>> I can also setup a virtual machine (at OVH) to run them.
>>>
>>> Cheers,
>>>
>>> -sbi
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>
>
>
> --
>
>
> camptocamp
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> Joël Grand-Guillaume
> Division Manager
> Business Solutions
>
> +41 21 619 10 28
> www.camptocamp.com
>
>
>
> _______________________________________________
> 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
>