openerp-community team mailing list archive

[Fabien Pinckaers <fp@xxxxxxxxxxx>]

In order to move forward, the next step is to draft a community
statement on the role of OCB branches. Because it looks like you expect
more than the initial goals (backport of bugs fixed in trunk on v7)

What do you expect from the ocb branches? Possible answers:

1/ A more "up-to-date" branch where bugfixes are applied by the
   community faster than in official v7.
2/ A way to improve collaboration OpenERP SA-Community by having a way
   to simplify the code review process for OpenERP SA to merge faster in
   stable.
3/ A branch where you can push nice-to-have or wishlist features that
   you need for your projects or community modules
4/ A branch where you can improve the code in a more 'clean' way by
   breaking API, schema...
5/ A way to change design decisions such as default behaviors or values
   on which you may disagree on the path chosen in the stable branch


And it's important to balance this, with the 'cost' or responsibilities
indirectly linked to these roles:

1/ If the goal of ocb is to have a more stable branch, are you ready to
   apply strict stable policies which slows down the MP process and
   forces to refuse more MP.

2/ If the goal is to have both project (ocb-stable) to benefit from
   each other, are you ready to accept our code review decisions so
   that you can continuously merge back stable into ocb. (e.g. if we
   revert some of your changes while doing our code review and merging
   ocb in stable, would you merge this change back to ocb or will you
   maintain separate features?)

3/ If you want to push new features in OCB rather than putting them in
   community modules, are you ready to accept potential new regressions
   and bugs.

4/ If you want to be able to break API or schema to improve code, are
   you ready to pay an extra effort every time you want to apply latest
   bugfixes in your production environments. (no conflict with your
   custom module, -u, ...)

5/ If you want to use ocb to apply others design decisions than the
   stable one, are you ready to maintain this fork for the long term?
   v8, v9, ...


If we succeed to answer these, then everyone will probably agree on the
best way to organise MP and ocb branches.

On 10/29/2013 10:09 AM, Joël Grand-Guillaume wrote:
> 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
> <mailto: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
>     <mailto: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 <http://www.camptocamp.com/>
> 
> 


-- 
Fabien Pinckaers
CEO OpenERP
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com