openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

On Wed, Nov 6, 2013 at 10:48 AM, Joël Grand-Guillaume <
joel.grandguillaume@xxxxxxxxxxxxxx> wrote:

> Dear all,
>
>
> First thanks you Michel to take the time for that ! Now, I'm a bit
> concerned because we didn't really face this before.
>
> The
> https://code.launchpad.net/~openerp-community/openobject-addons/7.0-booking-chart
> is more a module that should be included in one of our project, and I
> don't which one, any idea ?
>
> Then the branch of the
> https://code.launchpad.net/~openerp-community/web-addons/7.0-web-unleashed
> is on the right place, but it contains a branch replicated from github...
> That prevent any merge to be done in the "official" community branch here :
> lp:web-addons<https://code.launchpad.net/%7Ewebaddons-core-editors/web-addons/7.0>
>
> That's a bit sad.. Any suggestion here ? How to handle GitHub branches ?
>


Hello Joël and others,

if a branch is Github driven and replicated on Launchpad, merging a
Launchpad MP isn't that hard: in your git branch just import the branch
using the native git ber remote helper
http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/
merge inside your git using usual git merge command, push to Github (then
auto-replicated to Launchpad) and voila! Still Github submitted merges are
easier to deal with.

Of course, now if a module should integrate a branch driven on Launchpad,
then probably it's better to let it be developed on Launchpad.

Now a bit more about this: "should a module integrate some existing
Launchpad branch?"
In any case, people should remember that we currently group modules
together just because OpenERP don't have any decent package manager that
deal with version constraints and multiple repo location. And as you read
this, please OpenERP SA don't try to reinvent a package manager (apps?),
that's something hard, OpenERP should standardize instead of wasting
resource on these solved problems.
And again, it's not like if I am only "talking":
https://code.launchpad.net/~akretion-team/openobject-server/trunk-extra-depdencies-info/+merge/114172

But in any case, grouping modules in the same branch is rather a temporary
artifact and a bad design than anything else.

Instead, once it becomes decent to install pinned versions via package
manager and test with standard Continuous Integration tooling,
**we should tend to 1 module = 1 branch**
That's how all the modular dynamic ecosystems work. Of course, we could
still have a few exceptions. If you take the Ruby ecosystem (extremely
modular and works well), you see that usually 1 module = 1 Github repo. But
as for the Rails repo, it's 5 modules altogether in the same repo (but only
5, while a typical Rails project will depend on 50+ modules). It's an
exception and it still works. I know it less, but I think it's the same for
Pypi, right?

If we keep grouping modules blindly, that will not scale in term of
complexity: soon there will be tons of merge for modules that are unknown
to most of a project team, that will be slow/frustrating or badly reviewed.
We will have branches of these god branches incompatible between them and
branch cross dependencies nightmares.

With that in mind, I think it would be an error to think that only a few
people should determine a single forge for all the OpenERP eco-system,
specially if that forge sucks (I didn't tell Launchpad sucks, you are
interpreting here ;-)

I think it really make sense to use a single forge for the core, but as for
the whole eco-system, we would try to impose bad tooling to good willing
people and that will not work.

It's cool also to have OpenERP SA and OCA doing some centralization work
trying to develop and review core modules, but in any case, it will never
scale to imagine that just a dozen of people will review the entire
eco-system at every-commit. I think that instead there will be lot's of
projects, lot's of team, ideally good practices in many places and possibly
some centralization but only for the core things. If if try to centralize
and decide for everything, then we will have a sub-optimal core (because
work is diluted with non core things) and a frustrated community that see
its freedom to innovate restricted.

Now
<my personal opinion about Launchpad and bzr>
it does the job, but hell it doesn't do it well. Here it's very common that
bzr branch --stack addons takes over 20 minutes (1h30 without stacked) vs 8
minutes for the same Github shallow clone. Want to compare
purchase_requisition in 7.0 against trunk? in git it's a breeze, in bzr
slow as hell. If you have a bzr branch that you want to do pull after some
2 months (branch for some customer?), bzr pull can easily take more than 1
hour... (and we tried everything, local bzr mirrors etc...)
Also I don't see much activity on bzr repo to fix this. It isn't really
cloud ready and it's like both bzr and Launchpad are loosing the battle
here.
So I'm perfectly okay to contrib on Launchpad. But when I do so, I always
think it's temporary and that one day anyway Launchpad will probably
announce that it's closing and we will need to put all these little team
and karma in the trash and move all that to some git (or hg) forge.
Other things I don't like about LP: it really badly sells a project:
navigation is awkward to newcomers, documentation isn't integrated, project
dynamism doesn't drive to adhesion. Also, we aren't as rich as SAP or
Microsoft, right? So what we need? We need contributors hell! but again
Launchpad badly reward contributors vs Github that does it so well that a
Github profile starts to be what a recruiter will look at to evaluate a job
candidate (compare this to hackable karma...)
Anyway this is just
</my personal opinion about Launchpad and bzr>
(now I said it)


So as a conclusion:
I say no to a dogma that we should group modules inside the same branches.
That's only a temporary work-around while some believe or make believe
things like apps is more important than pip modules.

In the meanwhile, it's not because that there are several branches that
there cannot be projects hub and their teams: a common team could take care
of several projects, on several branches and possibly forges.


Finally, I think we should investigate the great work of Vo Minh Thu
regarding OpenERP module packaging:
http://assertive.io

My issue still is: if we have a new addons version at every commit, then
for any delta update pip update of the addons it will probably re-download
400+ Mo of all the fresh addons vs a few ko if you were doing a bzr or git
pull. Again, not exactly cloud ready...
Given the very relative stability of OpenERP, I only have seen success of
people doing these delta updates on their projects to fix bugs as they
encounter and fix them. Today I don't see this working with assertive yet.
I may just be dreaming, but instead I was thinking about something like:
for all modules we have git-subtree (no working bzr equivalent!) cron that
put every module in a single branch: the module version get incremented
only if this particular module receives a commit. Possibly, a translation
commit is the z of the x.y.z semver. Then doing pip update would
re-download the module only if it received commits, and possibly only if
these commits aren't just translation.


My two 2 cts. Thanks to all for these input about that essential topic.


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com