openerp-expert-framework team mailing list archive
-
openerp-expert-framework team
-
Mailing list archive
-
Message #00958
Re: Making our way out from the bloated extra-addons repository
Hi Valentin
On 11/01/2012 03:50 PM, Valentin LAB wrote:
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'm really +1 on that one : I missed most of this thread (simply because
my mailbox is overflooded), and find it hard to get a clear picture from
what the different persons have written there.
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.
We @anybox have done this in the past, well, mostly because we didn't
want to interfere with projects with similar names, but we are also
really open to renamings if many people are interested in code we bred
(that means also that more people have checked there's no naming conflict)
- 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.
OpenERP SA is developping right now a new approach of testing which imho
goes really in the right way : base unittest2 classes, insulation of yml
tests in their own transaction,
These are some of the topics that have been discussed during this week's
sprints.
We can reasonably hope that v7 will come with clear guidelines about
that. It'd be the community best interest then to follow these guidelines.
In short: maybe we should be patient
About continuous integration, see below ;-)
- 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.
Well, of course you won't be surprised if I'd support the buildout
approach, since we have a buildout recipe that's designed to bring
together different sources of addons directories, among wich tarball
downloads, git/hg/bzr repositories with revision/tag pinning,
Besides, we (Anybox) already have the continuous integration tools that
follow buildout cfg. files and can load those configs from an online
repository, so that adding new combinations would be real easy.
In short, if sets of addons are encoded as buildout cfg files, automatic
build of them in http://buildbot.anybox.fr would be a no-brainer for us,
just a matter of horsepower by adding more buildslaves. We don't have
more resources to allow right now, but the community could provide
buildslaves in return of the general infrastructure, that's also real easy).
I'm not sure git submodules would be flexible enough for that kind of
purposes, but I must admit not knowing them so much. Can you for
instance pin some on different tags, while keeping the other ones live
for commit tracking ?
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.
Well in some cases, it's better to version a few closely related modules
together. For instance to separate the web part from the main server
business logic.
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.
Follow ups
References