openerp-community team mailing list archive
-
openerp-community team
-
Mailing list archive
-
Message #03711
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
Dear Fabien,
First, thank you a lot for your input in here, this prove (as you said)
your interest in that ! For being too rude, there no problem on my side, I
know you for quite a while now and I won't take it personally, I always
preferred the thinking being said ! That's the way we move things !
We do use OCB at Camptocamp without exception in ALL our customers
projects. I share more than ever Stefan's Opinion :
"
*So we still disagree (no surprises there) but OCB is working perfectly for
us. When running OCB, we can be sure that every approved bugfix that we
supplied is included so that we don't encounter the same bugs again for
every customer. A dedicated group of community developers (and their
customers) is benefiting from each other's quality bugfixes and reviews. I
love it. It has taught me a lot on programming, communities, code standards
and OpenERP itself. It has improved my life with OpenERP in terms of
practicalities and got me in contact with a lot of knowledgable and
friendly people that I now consider my extended colleagues.*
"
Reasons for OCB to exists:
* We can share efforts between well experienced integrators to fix and
ensure those fix in time for our customers
* We really have now a strong knowledge in there that probably exceed
yours in various areas (no offense)
* We can fix what OpenERP SA don't want to consider (for good and some
times no good reasons IMO)
* We have a way to react much more faster when facing a trouble, and my
customers are very happy with that trust me (OPW works, but take a hell of
time until it land in our customer server)
* In complex integrations that we do, some changes are required to make
OpenERP work in production, changes that my not be compatible with your
policies. That do not need we don't need them !
On your remarks:
* OCB didn't introduce more bugs (or not more than you do), some tests
fails because they are wrong and need to be adapted / corrected that's
probably 99% of the reasons why OCB is not green !
* OCB do take some other choice than OpenERP SA do regarding some "won't
fix" or "invalid" bugs as we do not consider those bug as this. It's may be
a matter of opinion, I respect that. I can't simply say to my customers I
don't want to fix, you have the right of saying so.
* OCB reviews are probably as good (and IMO better) than yours. We can
make mistake, that's human. We really take care about what we're doing here
and that comes from the most skilled partners and integrators you have. If
they don't make things good who do ?
* OCB need to improve on the review process and tests I agree and we're
working on it !
My personal opinion concerning OCB (that's just me) is that in some time
(not that long, may be a year or two), OCB will be more than a reference.
We'll grow as a community, we'll get stronger and better. And we'll one day
have more resources than OpenERP SA it-self (which is not the case yet). As
you said, the question is know how to better integrate OCB with Stable (and
vice-versa) to benefit from that.
We're on the same ship here as always. Everyone has his own interests about
keeping the stable policy here and make it different there. At a point, you
may not agree on some changes, that's your right. We think the changes
we've made are mandatory. We are ready to manage and maintain those changes
for the good of our customers.
So, at the end, the question will be : How OpenERP SA can benefit from us
;) ?!
I'm not in favor of having 2 OCB branches (too much work). I think OCB
should be part of the Official project (it deserve it). Weekly merge from
OCB to Stable should be done with your review (accepting what you want, and
not what you don't). This is manageable and you will still get lot's of
input from us (making the bugfix process quicker). You'll spend less time
merging our work with some filter rather than re-making the fix we already
did.
A day or another, the OCB changes will land in trunk or die depending on
the fact it has been proven to be mandatory for everyone or a mistake from
us (OCB team). I make the bet we're gonna be right more than you may think,
but surely not always.
I see no better solution given the interest of both of us, and I consider a
good one, what do you think ?
Thanks for all this enthusiast,
Cheers
Joël
On Tue, Oct 29, 2013 at 7:31 AM, Fabien Pinckaers <fp@xxxxxxxxxxx> wrote:
>
> > Sorry but my feeling is this suddent interest from S.A. in OCB is more
> about "control" and "fear"... If you really want to help, stop spreading
> FUD
>
> No. Sorry if I was not clear.
>
> My only intention is to have an ocb branch that works so that people can
> rely on it and we can easily merge it in stable to improve ocb.
>
>
> I seriously think that if we define a better policy and process than the
> current one, ocb can become a great way to improve community contribution
> to the stable branch.
>
> I also think that if you continue diverging from the stable and accept
> anything in ocb branches, ocb will become less and less interesting for the
> community.
>
> My preceeding mail is may be too rude. But I really thing it's important
> for ocb branch to setup a test server and a better merge policy.
>
> As I said; this is my point of view and we will support your decision
> about what you want to do with ocb.
>
>
> > and start showing that you respect and appreciate the work from our
> community, and that is only possible with ACTIONS, not words....
>
> I do appreciate the community and such great contribution. (OpenERP would
> not be open source, if we did not have an inconditionaly full support for
> open source and community)
>
> If I participate to these mail, it's to help ocb move forward and do even
> better. Do you think it's better if don't tell you what we think?
>
> I think ocb can be great if we improve a few things (runbot, clear policy,
> stricter code review) and that's the reason why I give you my point of view.
>
>
>
>
> Fabien
>
>
> _______________________________________________
> 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
>
--
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
*Joël Grand-Guillaume*
Division Manager
Business Solutions
+41 21 619 10 28
www.camptocamp.com
Follow ups
References
-
Proposal to improve communication and make more efficient the inclusion of new branches.
From: Nhomar Hernández, 2013-10-22
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Quentin THEURET, 2013-10-23
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Fabien Pinckaers, 2013-10-24
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Ronald Portier, 2013-10-24
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Fabien Pinckaers, 2013-10-25
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Olivier Dony, 2013-10-25
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Stefan, 2013-10-25
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Joël Grand-Guillaume, 2013-10-28
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Olivier Dony, 2013-10-28
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Fabien Pinckaers, 2013-10-28
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Stefan Rijnhart, 2013-10-28
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Mario Arias, 2013-10-29
-
Re: Proposal to improve communication and make more efficient the inclusion of new branches.
From: Fabien Pinckaers, 2013-10-29