Forgot this link about the review process for you Michel :
https://doc.openerp.com/contribute/05_developing_modules/#community-review
On Thu, Nov 7, 2013 at 10:06 AM, Joël Grand-Guillaume
<joel.grandguillaume@xxxxxxxxxxxxxx
<mailto:joel.grandguillaume@xxxxxxxxxxxxxx>> wrote:
Dear Community,
First, I want to thank you Michel for trying to respect the
community process and tools. I know it's a bit of work, but it's
mandatory to maintain quality. I hope you had all your answer
(making a fork and go through Merge Proposal when requesting an
update, so the review can occur, even for your first one).
Secondly, I'm completely in-line with Perdo's opinion about what
goal do we pursue. It took us (and me) lots of time to setup all
those LP repository, team, branches and all that stuff to make the
OpenERP community a reality.
Now we finally reach something.. Thanks to all of you ! It starts
to work and attract the interest of people and I'm really happy on
that.
But, even if I know LP and Bazaar sucks on some points, it works.
It's organized, reviews are made and the process and tools are
clear enough to enough people do the job.
For that reason, I'm strongly in favor of keeping our work there
for now. We barely have enough resources to make all the needed
reviews and I think moving to GitHub will not help on that but
rather introduce quite lots of overhead till we reach what we have
now.
My suggestion is :
* Keep LP and Bazaar for now and at least, let's say a year or two
* Keep improving the reviews process, docs and so on so new
comers can join the effort
* Starts to run the OCA (we're working on it this month)
* When we starts having a comfortable situation, let's move to
GitHub or anywhere else you want, I actually don't really care
about the tools. I care about building this community and make it
stronger.
I know Raphaël, you angry with Bazaar and Github is better suited.
I know you find the packing system a pain in the ass and I agree.
But let's make with what we have till we're strong enough to
change that !
Regards,
Joël
On Wed, Nov 6, 2013 at 5:32 PM, Pedro Manuel Baeza Romero
<pedro.baeza@xxxxxxxxx <mailto:pedro.baeza@xxxxxxxxx>> wrote:
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
<https://lists.launchpad.net/openerp-community/msg03629.html>
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 <http://apps.openerp.com>.
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
<mailto:rvalyi@xxxxxxxxx>>
On Wed, Nov 6, 2013 at 10:48 AM, Joël Grand-Guillaume
<joel.grandguillaume@xxxxxxxxxxxxxx
<mailto: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
<https://code.launchpad.net/%7Eopenerp-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
<https://code.launchpad.net/%7Eopenerp-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
<https://code.launchpad.net/%7Eakretion-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 <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/#%21/rvalyi>
+55 21 2516 2954 <tel:%2B55%2021%202516%202954>
www.akretion.com <http://www.akretion.com/>
--
Mailing list:
https://launchpad.net/~openerp-community-reviewer
<https://launchpad.net/%7Eopenerp-community-reviewer>
Post to :
openerp-community-reviewer@xxxxxxxxxxxxxxxxxxx
<mailto:openerp-community-reviewer@xxxxxxxxxxxxxxxxxxx>
Unsubscribe :
https://launchpad.net/~openerp-community-reviewer
<https://launchpad.net/%7Eopenerp-community-reviewer>
More help : https://help.launchpad.net/ListHelp
--
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
*Joël Grand-Guillaume*
Division Manager
Business Solutions
+41 21 619 10 28
www.camptocamp.com <http://www.camptocamp.com/>
--
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
*Joël Grand-Guillaume*
Division Manager
Business Solutions
+41 21 619 10 28
www.camptocamp.com <http://www.camptocamp.com/>
_______________________________________________
Mailing list: https://launchpad.net/~openerp-community
Post to : openerp-community@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openerp-community
More help : https://help.launchpad.net/ListHelp
