Community mailing list archives
Re: New OCA repository to suggestby
Akretion, Raphael Valyi
these things or more mid/long term but I think Leonardo Donelli made some good points here. Basically it's extremely important OCA leaves the module author visibility very explicit because it's really a large part of what can make it sustainable to invest in OCA: you can save on marketing expenses on all kinds because OCA gives you back some acknowledge of your skills and dedication in the project (other large economic motivations are integrated roadmap and lower maintenace costs through better quality and shared work).
Let's be lucid: tomorrow some people may value Odoo a lot by trying things like hijacking the license or trying to take over the whole network the license suddenly it's worth a lot of money at the expense of our freedom. Against such plans, an open source way of doing things will only stand if it is economically sustainable for community members to invest on open source. The license doesn't make it easy, but that's the rule we all accepted to build what we built years ago and now, that's also the only warranty of freedom, so we should not screw the other remaining aspects of the business part of the thing.
Now, technically speaking, I think Leonardo Donelli presented something doable:
There are some successful projects where indeed, root repos are just a curated list of git revisions to pull to assemble the software.
An example, look how Getchef (formerly Opscode) disribute its Erlang Chef server:
This repo is almost empty but this is where you will pull from: it's only a curated list of valid commit to pull from other repos. And that works great.
And this is recursive, look for instance:
Here there sometimes bother with putting a flag, but most of the time a module version is simply a commit revision that is properly pinned in the dependencies specification.
In their case, it's the packaging rool (Rebar) that does the work. Other projects work the same with other packager.
So we certainly have other priorities for now, but I personally would like such way of doing in the future.
Another random though about having modules together in a branch: I think that is an acceptable topology for modules that OCA reviewers agree they are important and generic if and only if it leaves the repo depending only on the official addons branch repo (and mat be a unique OCA repo too like server-tools, to be debated). If another dependency is needed, that could be a formal rule to use to tell today that the module should already live in it's own repo.
On Sat, Sep 20, 2014 at 1:22 PM, Leonardo "LeartS" Donelli <firstname.lastname@example.org> wrote:
Daniel: your point 1 is the solution to point 2.
Submodules are fixed at a certain stable commit an to be updated one would do a pull request to update the submodule commit.