Hi, community,
Sorry in advance for the long message.
I think we have to talk about two different topics that are
under the OCA umbrella: OCB branches and community repositories.
For OCB BRANCHES, there are not too much discussion: it's
mandatory that we have them on Launchpad, because there are too many
dependencies on LP that cannot be avoided (see this Olivier Dony
answer[1] about this question on other thread) and we must go here
together with OpenERP S. A.
About COMMUNITY REPOSITORIES, the question that Raphael has
exposed is critical: the future and maintanability of them. Having
lived a part of the evolution of them, this is what I think:
* In some way, we are trying to compensate the lack of a global
quality OpenERP repository. OpenERP Apps doesn't count, because the
categorization in it is not very accurate (it depends on the module
manifest) and there is a lot of "dummy" modules that makes a few
(usability module, for example).
* The only way we have for now is to group relevant modules in a
repository to make it in somehow available to the groups of interest.
* We have used Launchpad to continue with the same tools as the
mother project.
* These tools have conditioned the organization / reviewing process.
* Although we are admitting a lot of new modules, it follows some
criteria (for now based on the sense of the reviewers) to avoid only
usability modules (we have talked about this on other thread also).
* Reviewers can use their expertise to teach newcomers on good
practises, and these newcomers will be soon the next teachers (this
is for example my case). This musn't been interpreted as a
dictatorial regime, but some work rules to assure quality. If these
practises are not correct, we can change or refine them.
* We don't have the obligation to maintain across the versions all
the modules that are included in some momment on the community
repositories, but to assure that when something arrives to them (a
new module or an adaptation to a new version of an old one), it has
enough quality to enter.
* These reviewings can be exhausting, but we are attracting each
day more contributors that helps with this process.
* Nobody have the obligation to publish their modules on community
repositories. They can use their own repositories, even hosting on
others CVS.
* My hope is to set these repositories as the reference where
someone goes when he wants to contribute.
So, said that, to keep this initiative healthy, this is IMHO what we
have to do:
* Set clear rules for the reviewing process. This is already done
and will be merged on official documentation.
* Set a path to contributors to become reviewers.
* Reward contributors with some visibility on OCA mediums (web and
so on), to encourage new contributions.
* Set rules for admission of modules. This is not easy, but it can
be done with a few exceptions.
Now, about LAUNCHPAD AND GITHUB, I feel the same as Raphael in the
questions he told (performance, acknowledgment, subprojects, etc),
and maybe we can switch community repositories to GitHub to avoid
questions like the one that has started this debate, but this must
be assured:
* We have a way to integrate translations for easy contributions.
I'm already working on having Launchpad translations on community
repositories and I see this as mandatory.
* We must assure atribution and permissions.
* We cannot lose contribution history.
* Reconstruct documentation with the new contribution path.
* We must have anyway synched Launchpad repository/repositories to
enable modules on apps.openerp.com[2].
As you see, this a lot of work to do and questions to solved, but
Raphael, if you're willing to work on this, I can help you and
propose to the community a concrete proposal to make the switch.
Regards.
2013/11/6 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[3]
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[4]
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[5]
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[6]
+55 21 2516 2954[7]
www.akretion.com[8]
--
Mailing list: https://launchpad.net/~openerp-community-reviewer
Post to : openerp-community-reviewer@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community-reviewer
More help : https://help.launchpad.net/ListHelp
