openerp-expert-framework team mailing list archive

[Valentin LAB <valentin.lab@xxxxxxxxxxx>]

These are lot of great ideas, and I'm quite happy to see all this moving 
forward.

Important points are being stated, explained, and it might be time to 
gather them in a central document which could help defining which type 
of community we are sketching.

I'm afraid that those important step could vanish. And I've minor 
concerns on some topics, but I don't feel that's enough to make a 
mailing list post.

In short: could we move on a stable collaborative media to start writing 
down what seems to hit consensus and to gather and count people 
interests and motivations ?

I was thinking about simple tech as google docs or etherpad. I'm not 
sure this is the right time to do this or if this is a good idea, so I 
await some reaction to create a etherpad (I can provide this, as any of 
you I suppose).

- I'm one hundred percent for removing names of company in modules, and 
your argumentation is perfect also, even if I was already convinced on 
this point.
- I'll be using mirrors on github provided they become a sure reference. 
(I'm using only git and translate all bzr to git already)
- We need QA, and conventions. There are simple decisions that could be 
taken in this matters (enforce PEP8 and a specific pylint profile). I 
have wet dream of review pre-commit... github is perfect for this with 
the pull-request feature.
- So restriction of commit should be applied and restricted on a known 
basis (for example: at most X positive reviews, and tests and code 
conventions passes). For the community's sake, a company should not be 
granted special rights (as new recruit from this company could easily 
commit bad code), but some individuals should have special position 
acknowledged by the community.
- For QA, we need broad reflection on testing. I'm not sure there's a 
consensus on what, why, when, and how to do tests and what is a test. 
But even if this discussion will have to happen one day, there are 
plenty of tests already written in various language that should be ran 
daily on integration and pre-commit. And I think we should focus on that 
first.
- if OpenERP SA is not willing to make versioned dependence between 
modules, we should enforce it (provided we are enough to share this 
point of view). There are plenty of solution, among them are some 
patches on the openerp-server code and these patch are not so big and 
could be maintained with not so much hassle. There are other solutions 
as well that don't need any patch on openerp code, for example : 
maintaining a database of modules name along with their respective 
commit number that are supposed to be compatible -- there are numerous 
examples of this in software, and especially in python (where you can 
pinpoint packets by version in setup.py, buildout.cfg, or even KGS -- 
http://good-py.appspot.com/, 
http://download.zope.org/zope3.4/3.4.1/versions.cfg), even "git 
submodules" does this pretty well.
If we find a good way to do this, this would allow to remove 
intermediate groups of modules you are suggesting. As I would rather 
have one module per branch ultimately, but I understand that it's better 
in current condition to keep going in multi-modules in one branch.
I'm not really fond of "web_google_maps" being alone in its own module set.

- We need more Community managed Code Sprint to get to know each others 
and when possible, try to avoid making code sprint in the middle of 
nowhere on a date that wasn't discussed before between community members.

- Git historic rewriting proficiency is proverbial so if you encounter 
some difficulties to tear apart some bzr repository while keeping 
historic information, this is quite easy with git (and I must recall 
that bzr to git conversion with full history is trivial).


As a side note, I'm concerned by the fact that this thread could have 
been about openobject-addons (to some extent). If something emerges from 
extra-addons, this could eventually lead to better code everywhere in 
the openerp community.


--
Valentin LAB --
https://github.com/vaab
https://github.com/0k

tel:  +33 6 71 39 62 13
mail: valentin.lab@xxxxxxxxxxx