openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello,

my suggestion is:
1) do v8 dev on Github only and as soon as we have our new branches.
2) do business as usual for some time on 6.1 and 7.0 on LP while we still
work marginally on v8 and while we still have most of MP on LP with 6.1 and
7.0 MP.
3) then, as people will transition to v8, the volume of MP on Github will
naturally pass the volume of work been done on LP. So we could then
transition 6.1 and 7.0 maintenance on Github directly (still mirrored on LP
for convenience). May be in 6 months from now.

As I said, I can help for bzr to Github migration as I have done it
extensively since 1 yea for server, web and addons projects.
The thing is I'll fly back to Brazil in 2 days, so this is not exactly the
moment I can help sadly.

My scripts are able to do cron synchronization of a collection of LP
projects with several branches. They are minimal and need some comments.
The plumbing code between the git commands is currently all done in Ruby
(because this is the language I'm the most efficient with). May be 30 lines
of Ruby at the moment. I'm willing to work on that to help the migration
but of course I would not want spend further effort on that if that's to
hear at the end that we cannot run a Ruby script or if that is double work
with somebody else.

Regards.


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



On Mon, Jun 23, 2014 at 7:04 AM, Leonardo Pistone <
leonardo.pistone@xxxxxxxxxxxxxx> wrote:

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