openerp-expert-framework team mailing list archive

[Ray Carnes <rcarnes@xxxxxxxxxxxxxxxxxxx>]

Can I also suggest adding the recommendations about module versioning from
OpenERP?

http://doc.openerp.com/trunk/developers/server/module-versioning/

There are many problems that users face not installing the correct
versions of modules.

Ray.

-----Original Message-----
From:
openerp-expert-framework-bounces+rcarnes=ursainfosystems.com@lists.launchp
ad.net
[mailto:openerp-expert-framework-bounces+rcarnes=ursainfosystems.com@lists
.launchpad.net] On Behalf Of Georges Racinet
Sent: Thursday, November 01, 2012 9:34 AM
To: openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openerp-expert-framework] 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.
>
>


_______________________________________________
Mailing list: https://launchpad.net/~openerp-expert-framework
Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-expert-framework
More help   : https://help.launchpad.net/ListHelp