I wonder if a monkey patch would work - they are all python constraints
basic logic, copy the constraints lists to some other list of lists,
reassign obj constraints in module to []
assign back when needed
general idea
addon_constraints = [openerp.addons.account_constraints.obj1._constraints,
Hello,
Thanks that is an option but difficult to implement in travis. I also want
to test account_constraint if possible.
Maybe your right, split the addons in a seprate branch or repo is the easy
solution.
It is also a problem we will encounter in other project under some
circonstancies, so
I need advice to setup travis for account financial tools.
The addon account_constraints adds a lot of constraints and make other
addons tests fails.
Nicolas,
You could try splitting up tests into different build jobs:
On 07/03/2014 09:08 AM, Guewen Baconnier wrote:
* Module A add a 'required' on a field of model product.product (or a
new required field)
* Module B does not depends on module A (because there is no reason to),
creates a product for its own test, will fail because the required field
added by
Hi Nicolas,
I'm curious to see which tests fails due to account_constraint. Do you have
a pointer?
Could the incompatibilities be resolved by adapting the failing tests to
satisfy the constraints?
-sbi
On Thu, Jul 3, 2014 at 7:57 AM, Nicolas Bessi nicolas.be...@camptocamp.com
wrote:
Hello,
Hi Stéphan
The tests mainly fail on the period_id constraint, so we can fix the tests,
but it is a workaround.
For the rest they are broken tests to be fixed one by one.
There still is the cases of the credit control modules that uses scenarios
as tests depends on a complex vertical settings.
I
Hi Daniel,
On 06/30/2014 11:19 PM, Daniel Reis wrote:
Hi Guewen,
Then, those maintainers will be responsible to do each step for the
selected projects according to
https://github.com/OCA/maintainers-tools/wiki/Migration-Launchpad-%E2%86%92-GitHub#migration-steps
I think need some
All the steps are there:
https://github.com/OCA/maintainers-tools/wiki/Migration-Launchpad-%E2%86%92-GitHub#help-on-the-launchpad-mirroring
My bad, I didn't realize those instructions were in the same page. I
added an internal link for other blind people like me to see it.
Regards
/DR
Sandy proposed to rename the modules with _unported to avoid them to
be checked by Travis. At that time I didn't recall that modules where
moved in __unported__ in 7.0 (it had been discussed but I don't think it
has been done on 7.0 branches, at least on most of the projects, I'm
sure I
On 07/01/2014 09:37 AM, Daniel Reis wrote:
All the steps are there:
https://github.com/OCA/maintainers-tools/wiki/Migration-Launchpad-%E2%86%92-GitHub#help-on-the-launchpad-mirroring
My bad, I didn't realize those instructions were in the same page. I
added an internal link for other blind
Hi,
Reminder to maintainers: *Please do not merge Pull Requests on GitHub
on project that have not switched to GitHub!*
Otherwise we won't be able to sync the GitHub branches from Launchpad
without troubles.
Here is the dashboard of the migration:
Hi Guewen,
Then, those maintainers will be responsible to do each step for the
selected projects according to
https://github.com/OCA/maintainers-tools/wiki/Migration-Launchpad-%E2%86%92-GitHub#migration-steps
I think need some assistance on some of the migration steps:
2) I found necessary
Hello Sandy.
I intend to setup continuous integration setup for OCA/switzerland. I'm not
found of the fact to rename addons to avoid them to be tested.
I would propose:
If a branch is not ready to be tested (nothing ported) it should simply not
have any travis.yml file
Using python ast to eval
On Thu, Jun 26, 2014 at 9:22 PM, Sandy Carter
sandy.car...@savoirfairelinux.com wrote:
Just a point: In OCA/canada, I have been renaming the folders of
uninstallable modules to modulename_unported with _unported at the end
to help travis not test these modules.
I updated the wiki regarding
On Thu, Jun 26, 2014 at 9:26 PM, Stefan ste...@therp.nl wrote:
Hi Guewen,
thanks again. I've checked banking-addons (account_banking series),
web-addons and server-env-tools.
I was a little alarmed to find that a small number of directories were
missing from git, but then I found out that
Last November we has a discussion on this in this ML:
https://lists.launchpad.net/openerp-community/msg04016.html
The conclusion was to move unported modules under a __unported__
directory (besides changing installed key to False).
/DR
Em 26/06/2014 20:22, Sandy Carter escreveu:
-BEGIN
Stefan,
I took it a little father and got a /git log /looking very similar bzr's:
git log --pretty=format:%h %an %ad %s --date=short --first-parent
Guewen,
Regarding OCA/project-service, history looks good also.
/DR
Em 26/06/2014 20:26, Stefan escreveu:
Hi Guewen,
thanks again. I've checked
Really good job of the community on https://github.com/OCA
Thanks to all
But a simple question.
The presentation on github is really wide (it takes a lot of space in the
interface) and then you have often to scroll and move to next page to
discover all the repositories.
Maybe we could have
2014-06-27 8:13 GMT-04:30 David Beal david.b...@akretion.com:
Maybe we could have localizations in a separate repos like
https://github.com/OCA_locale to avoid to have luxemburg or any other
locale repo between main repositories
I prefer take the approach of web hooks and present cool in
I agree we need to solve this out in a mid-term planning. But for now, we
concentrate all our resources on other more important topic.
For now, the most important regarding all this is to have every reop in the
same place. That matter a lot. Then we'll ask ourself about bringing more
visibility.
On 25-06-14 16:36, Guewen Baconnier wrote:
I'm currently copying all the branches to the OCA repositories [0] with
this script:
https://github.com/OCA/maintainers-tools/blob/copy-branches/tools/copy_branches.py
It can be launched again to pull the changes from Launchpad, so we'll be
able to
On 06/26/2014 09:15 AM, Stefan wrote:
On 25-06-14 16:36, Guewen Baconnier wrote:
I'm currently copying all the branches to the OCA repositories [0] with
this script:
https://github.com/OCA/maintainers-tools/blob/copy-branches/tools/copy_branches.py
It can be launched again to pull the
On 26-06-14 16:02, Guewen Baconnier wrote:
That's a good opportunity of course, but it seems to me that a
one-to-one migration first then a reconciliation after the switch will
be easier, since the one-to-one migration of branches is automatic and
the pull Launchpad→GitHub can be done several
+1 really good idea Stephan, it will be really great to have this two
projet merge together
2014-06-26 9:15 GMT+02:00 Stefan ste...@therp.nl:
On 25-06-14 16:36, Guewen Baconnier wrote:
I'm currently copying all the branches to the OCA repositories [0] with
this script:
Hi,
As you have maybe noted, all the branches are now replicated on GitHub
on https://github.com/OCA but are still to consider as 'read-only'.
Commits are still done on Launchpad.
As I generated the mapping file [0] semiautomatically, series older than
6.1 may be missing on projects that have
This is not strictly translation 2 github, but a project proposal that
could be included in the whole reorganizing:
A initiative, which probably could be part of the OCA projects as System
Tools or alike:
- https://github.com/WE2BS/openerp-openlib
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 2014-06-26 10:50, Guewen Baconnier a écrit :
4. Sandy added this great stuff to the project.
Thank you :)
5. Set modules to uninstallable with:
ack installable --py -l | xargs sed s/[\|']installable[\|']:
True/'installable': False/ -i
Hi Guewen,
thanks again. I've checked banking-addons (account_banking series),
web-addons and server-env-tools.
I was a little alarmed to find that a small number of directories were
missing from git, but then I found out that none of them contained any
files. I had trouble comparing the
On 06/25/2014 08:02 AM, Daniel Reis wrote:
Can you 'git push' back to the bzr remote?
DR
Yes, git-remote-bzr supports that. Note that we shouldn't need that here.
No dia 25/06/2014, às 06:45, Guewen Baconnier
guewen.baconn...@camptocamp.com escreveu:
On 06/24/2014 07:19 PM, Lorenzo
I'm currently copying all the branches to the OCA repositories [0] with
this script:
https://github.com/OCA/maintainers-tools/blob/copy-branches/tools/copy_branches.py
It can be launched again to pull the changes from Launchpad, so we'll be
able to sync them before the switch.
Meantime, please
Can you 'git push' back to the bzr remote?
Yes, git-remote-bzr supports that. Note that we shouldn't need that here.
Stéphane Bidoul proposed a migration strategy on this thread, on
21/06/2014, based on git-bzr-ng.
For short you:
* Use git bzr clone from Launchpad, and then git bzr import to
Hi Daniel,
We though about using the LP synchro against github to periodically pull
github branches. No need of special script here, so legacy deployments
should be fine.
Regards,
Joël
On Wed, Jun 25, 2014 at 4:48 PM, Daniel Reis dgr...@sapo.pt wrote:
Can you 'git push' back to the bzr
Hello Sandy,
What would you think about changing travis setup for OCA repoitories during
transition period in order not to be run if travis.yml is missing.
This will prevent failed build mail to be sent.
I would also really appreciate if you can give us again pointer to your
travis setup
Baconnier
guewen.baconn...@camptocamp.com
Envoyé: Mercredi 25 Juin 2014 14:25:06
Objet: Re: [Openerp-community] OCA: transition from Launchpad to Github
Hello Sandy,
What would you think about changing travis setup for OCA repoitories during
transition period in order not to be run
...@camptocamp.com
Cc: openerp-community@lists.launchpad.net, Guewen Baconnier
guewen.baconn...@camptocamp.com
Envoyé: Mercredi 25 Juin 2014 14:25:06
Objet: Re: [Openerp-community] OCA: transition from Launchpad to Github
Hello Sandy,
What would you think about changing travis setup for OCA
joel.grandguilla...@camptocamp.com
À: Sandy Carter sandy.car...@savoirfairelinux.com
Cc: Moises Lopez moylop...@vauxoo.com, openerp-community
openerp-community@lists.launchpad.net
Envoyé: Lundi 23 Juin 2014 18:31:41
Objet: Re: [Openerp-community] OCA: transition from Launchpad to Github
Hi Sandy
Hi,
There is still one point that is not totally clear yet, that is wether
we migrate only the 8.0 branch on GitHub or all the existing branches
(6.1, 7.0).
Excellent rationales for the full migration have been given by Leonardo
Pistone [0] and Laurent Mignon [1]. Read them.
Summarizing:
-
Hello,
As migration process can often be done by jump of 2 versions, it would mean
that for most of us we will have to keep both git and launchpad for at
least 2 years.
(It would be certainly more)
So even if its a pain for 1 month with MP to migrate:
+1 to move 6.1 + 7.0 to github now
Cheers,
the sooner we get rid of lp the better
+1 for migration to github asap
Eric CAUDAL
Eric Caudal
/CEO/
--
*Elico Corporation, Shanghai branch
/Odoo Premium Certified Training Partner/
*Cell: + 86 186 2136 1670
Office: + 86 21 6211 8017/27/37
Skype: elico.corp
eric.cau...@elico-corp.com
Hi,
I confirm what I wrote on Saturday.
Therefore +1 to migrate all branches to github ASAP.
-sbi
On Tue, Jun 24, 2014 at 11:18 AM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
Hi,
There is still one point that is not totally clear yet, that is wether
we migrate only the 8.0
Hello,
so while I'll have no time to tune a real script because unfortunately I'll
be travelling soon,
I took some time to write down the whole process of mirroring properly
Launchpad branches on Github.
I think all this is still valid even if Github branches becomes master
sooner even for the
+1 I agree also we should move all version to github. This give more work
on short term but at this end we will earn time.
2014-06-24 16:26 GMT+02:00 Raphael Valyi rva...@gmail.com:
Hello,
so while I'll have no time to tune a real script because unfortunately
I'll be travelling soon,
I
On 06/24/2014 11:18 AM, Guewen Baconnier wrote:
The existing merge proposals in progress:
The authors of the MP will have to move them to GitHub themselves if
they are not merged before the switch.
For sure, that's not nice to have to move them, but keeping the branches
on Launchpad for this
my bad, yesterday I did a mistake and copy-pasted the old method I had when
using git-bzr for the initial checkout, sorry for that. In fact using the
standard git remote helper (which I absolutely recommend), doing the
initial synchronization is much simpler and there is no need to create git
On 06/25/2014 04:01 AM, Raphael Valyi wrote:
my bad, yesterday I did a mistake and copy-pasted the old method I had
when using git-bzr for the initial checkout, sorry for that. In fact
using the standard git remote helper (which I absolutely recommend),
doing the initial synchronization is
On 06/25/2014 07:40 AM, Guewen Baconnier wrote:
On 06/25/2014 04:01 AM, Raphael Valyi wrote:
my bad, yesterday I did a mistake and copy-pasted the old method I had
when using git-bzr for the initial checkout, sorry for that. In fact
using the standard git remote helper (which I absolutely
On 06/24/2014 07:19 PM, Lorenzo Battistini wrote:
On 06/24/2014 11:18 AM, Guewen Baconnier wrote:
The existing merge proposals in progress:
The authors of the MP will have to move them to GitHub themselves if
they are not merged before the switch.
For sure, that's not nice to have to move
Hi, Guewen, count with me to help in the transition.
Regards.
2014-06-21 14:09 GMT+02:00 Bidoul, Stéphane stephane.bid...@acsone.eu:
Hi,
Some comments about migration strategy below.
On Fri, Jun 20, 2014 at 3:08 PM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
The
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
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
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
On 06/23/2014 11:16 AM, Joël Grand-Guillaume 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 Mon, Jun 23, 2014 at 12:58 PM, Lorenzo Battistini
lorenzo.battist...@agilebg.com wrote:
On 06/23/2014 11:16 AM, Joël Grand-Guillaume 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
On Mon, Jun 23, 2014 at 12:04 PM, Leonardo Pistone
leonardo.pist...@camptocamp.com 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
Il 23/06/2014 12:58, Lorenzo Battistini ha scritto:
On 06/23/2014 11:16 AM, Joël Grand-Guillaume 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
I started to work on the tools:
https://github.com/OCA/maintainers-tools
The first script is the one that copies the members of the maintainers
team to the other teams.
The branch also contains a function to login on GitHub using a token,
that should be shared by all the other scripts.
The other
HI,
I am also in favor of an earlier migration to github. We are a community,
and as such I would like to avoid introducing processes and tools that
would be specific OCA. The greater part of us probably have enough
experience to continue with both systems and even if IMHO it will introduce
a lot
Hello,
+1 with full migration to github... with scripts.
In github you will have new runbot available with PR for test it.
In github you will have just one tool of version control.
And you can make some script to migrate base branches and merge proposal
branches.
Note, in old runbot refactory by
On Mon, Jun 23, 2014 at 3:32 PM, Moises Lopez moylop...@vauxoo.com wrote:
Hello,
+1 with full migration to github... with scripts.
In github you will have new runbot available with PR for test it.
In github you will have just one tool of version control.
And you can make some script to
Ok, I agree on the principle as well (moving to github with mirroring on
LP). I let the responsiblity to gather the opinions and take the decision
to you Guewen.
On Mon, Jun 23, 2014 at 4:00 PM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
On Mon, Jun 23, 2014 at 3:32 PM, Moises
-community@lists.launchpad.net
Envoyé: Lundi 23 Juin 2014 09:32:03
Objet: Re: [Openerp-community] OCA: transition from Launchpad to Github
Hello,
+1 with full migration to github... with scripts.
In github you will have new runbot available with PR for test it.
In github you will have just one
On Mon, Jun 23, 2014 at 6:37 AM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
On Mon, Jun 23, 2014 at 12:04 PM, Leonardo Pistone
leonardo.pist...@camptocamp.com wrote:
Hi!
I am still convinced it would be somewhat less painful to have 6.1 and
7.0 in github, too.
Existing
: Lundi 23 Juin 2014 16:06:10
Objet: Re: [Openerp-community] OCA: transition from Launchpad to Github
@ Sandy, we already love your travis-pep8 combo and we are actively using it
(bacause style matters :) ). However of Runbot killerfeature of a running DB, I
wanted to ask, if you probably could
: [Openerp-community] OCA: transition from Launchpad to Github
Hi Sandy,
This is very interesting indeed ! What I can suggest is:
* You're part of the team that maintain the maintainers tools. I suggest
that you use this repository to share your work with a pull request :
https
openerp-community@lists.launchpad.net
Envoyé: Lundi 23 Juin 2014 18:31:41
Objet: Re: [Openerp-community] OCA: transition from Launchpad to Github
Hi Sandy,
You're right. I think the way out is to create a new project/repository called
runbot (any other suggestions ?) under the responsibility
sandy.car...@savoirfairelinux.com
Cc: Moises Lopez moylop...@vauxoo.com, openerp-community
openerp-community@lists.launchpad.net
Envoyé: Lundi 23 Juin 2014 18:31:41
Objet: Re: [Openerp-community] OCA: transition from Launchpad to Github
Hi Sandy,
You're right. I think the way out
Hi,
Some comments about migration strategy below.
On Fri, Jun 20, 2014 at 3:08 PM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
The decisions discussed so far
==
- The branches up to 7.0 will stay on Launchpad
Though, they will be mirrored on
Hi community,
I want to start to coordinate the transition of the OCA branches to
Github. Joël already created all the projects on Github, not without
sighs, thanks to him! We still have to create the teams, migrate the
code and setup the tooling for the maintainers / reviewers.
Several
On Fri, Jun 20, 2014 at 8:46 AM, Joël Grand-Guillaume
joel.grandguilla...@camptocamp.com wrote:
Comments in-line:
On Fri, Jun 20, 2014 at 3:08 PM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
Hi community,
I want to start to coordinate the transition of the OCA branches to
...continue...
We migrate from:
https://code.launchpad.net/openerp-mexico-localization
To:
https://github.com/odoo-mexico/odoo-mexico
2014-06-20 13:10 GMT-05:00 Moises Lopez moylop...@vauxoo.com:
Hello,
We make a simple mini-script to migrate to github from launchpad. (See
attachment)
*Comments in line*
2014-06-20 9:46 GMT-05:00 Ovnicraft ovnicr...@gmail.com:
On Fri, Jun 20, 2014 at 8:46 AM, Joël Grand-Guillaume
joel.grandguilla...@camptocamp.com wrote:
Comments in-line:
On Fri, Jun 20, 2014 at 3:08 PM, Guewen Baconnier
guewen.baconn...@camptocamp.com wrote:
71 matches
Mail list logo
