Contributors mailing list archives


Re: Proposal for new workflow, incorporating "Optimistic Merging"

Camptocamp SA, Joël Grand Guillaume
- 07/06/2016 14:19:46
Dear contributors,

I remind this post was initiated by Daniel, free to suggest any new ideas around (that was based on one of my twitt I confess).

The OCA has not yet decided anything here. We had a meeting to discuss how we can improve the PR queue and contributor experience. And that is damn needed ! Here is all the troubles we saw discussing the topic [1].

By no means the quality will be sacrificed in any solution proposed !

Among various possibility, Optimistic merging have its own pro and cons. It is not the solution to every of a problem.

On a quick update (before I find time to better explain what has been discussed) the following  first steps has been figure it out:
  • Define the automated bot rules to setup (process of review that can be automated) [2]
  • Expose the problem and solutions to the contributors and delegates
  • Ask delegates some questions in the General Assembly
  • Offer a quote (outsource) & Write the bot and put it in place
Once the process is define and the bot is in place to help managing the PRs, we might put in place two new steps along together:

 a) Certification program for OCA most strong and reliable module (e.g. 3 levels of "quality)
 b) Optimistic merging might be setup for quality level 1

The second step is just at a thoughts level, nothing more. On the first one, we're all convinced that it is more than needed ASAP.

Hope that it helps everyone to understand what's going on.

Best regards,

Joël for the OCA Board


Current problems

  • Time to merge, # of PR increases

    • → Generates frustration among new contributors

    • → Discouraging contributors

    • Reviewing is a boring activity

  • Travis is not always green

    • Lots of time taken to make Travis green

    • Not easy for newcomers to make it green

  • Merging rules might be too strict

    • PSC might have the right to merge faster? Yes, PSC can decide if merge something although some guidelines are not met.

    • Optimistic Merging (OM) instead of Pessimistic Merging (PM)?

      • Difference between new modules and existing modules ?

      • Difference between certified and not ?

  • Granularity of the projects

    • May be too large (too many modules)

    • Different maturity levels in the same projects/repo in term of quality, reliability, usage

    • Different level of maintenance among them (some are very active, others abandoned)

    • Different levels of responsibility from the PSC

  • Two goals managed the same way (may be time to split it up)

    • Make contributors modules visible among the community

    • Make a reliable modules on which people can rely on long term

  • Module duplication

    • A module name might already be taken by another non-OCA module in the community → OCA module does not appear on Apps

  • Repository dependency recursivity

    • Module A in repo 1 depends on module B in repo 2 and module C in repo 2 depends on module D in repo 1

  • Quality manage dependencies

    • Module at quality level N cannot depend on module at quality level < N


Automatic PR merging/closing

  • Put auto-rules in place

    • Close and comment ("Please re-open if necessary") every PR older than 6 month without comments

    • Merge PR of Quality Level 1 or tag "Needs fixing"

    • Compare the Quality Level from the module manifest with the one from the to determine if the merge is optimist or pessimist

    • Tag PR of QL > 1

      • With "New contributor" (people that has less than X commit within the OCA repos)

      • With "Needs review" if all CI are green, "Needs fixing" otherwise

    • Close every PR with tag “waiting from contributors” after 3 months without answer (+ post a message to explain why to the contributors) → No need as the PR can be re-opened, see the first bullet point)

    • Tag “new module proposal” or “improvements on existing”

    • Sent a reminder email with all PR proposed and pending to the author every week (or 2 week)

    • Post message in case of:

      • Travis red -> how to solve

      • Newcomers -> Say hello, thanks you, where to look for help + pointer to doc or relevant link

    • Tag PR among certified and noncertified modules

    • Make sure that the module name is not already taken using external sources (Apps, Pipy)

  • Parts of the solution

Note this module already interact with github and odoo

On Tue, Jun 7, 2016 at 4:08 PM, <> wrote:
Hi Community,

This thread remembers me the publisher who, for a while, did the 
marketing race to as many modules.

I thought one of the objectives of OCA's users and founders is to trust 
in a stable code.

How can we help to keep this way ?

Have a nice day,



ERP Project Director @ Savoir Faire Linux
More links :

Le 07.06.2016 09:09, Maxime Chambreuil a écrit :

> I agree quality is important, but you won't lose it by deploying from 
> packages. Packages will still have good quality.
> Keeping quality for packages will allow us to have collaboration and 
> innovation (which comes with unstability) in Github repos.
> The gateway between unstable repository and stable packages is a manual 
> release process.
> Le mar. 7 juin 2016 à 06:23, Rafael Blasco 
> <> a écrit :
>> Hi @ll,
>> I'm not agree in an optimistic merging approach. This opinion depends 
>> of what do you think OCA is and OCA can be.
>> OCA must ensure the quality of modules. This modules must be robust 
>> and never fail. OCA is a community that Customers take as reference of 
>> things well done, something that they can trust.
>> Odoo is an ERP which fight with the big ones and implement Business 
>> processes worldwide. This is not CMS. Two examples: (1) You cannot 
>> trust in 99% of wordpress modules (2) In Odoo Apps store there are 
>> many many modules that are more a problem for the customer than a 
>> benefic (even-though you pay for it).
>> When a customer trust in Odoo don't want to be optimistic, wants no 
>> risk for the investment. Customer must trust in OCA,
>> Furthermore, in my experience, I quoted projects based in "what is 
>> done thanks of OCA" so Customer can afford project. This was 
>> absolutely a big mistake and I must said "we must develop everything". 
>> Because you don't expect to find such a bugs that you must refactor 
>> everything. This means that optimistic merging will create a feeling 
>> of "uncertainty OCA".
>> Do we want more contributors? What is a contributor, someone who make 
>> PRs or someone who review PRs? Both. We need more reviewers too.
>> Code Contributors in OCA must thanks what they will learn thanks to 
>> OCA and the experimented reviewers. They will significantly improve 
>> their professional skills. With optimistic merging which is the 
>> challenge?
>> What will happens with the difference between contributors? The ones 
>> who make big efforts to make stable software, then ones who make quick 
>> software.
>> Maybe it should be an "OCA Quality" and "OCA optimistic", meaning of 
>> their stamps will be very different and the we will ask customer: do 
>> you want to be optimistic and take a risk? or do you want to be sure 
>> about what your business software will do?
>> Let's make last question. Why someone wants to put their modules to 
>> OCA?
>> - Because they will have visibility --> Why OCA have more visibility? 
>> Because you will find a well done work.
>> - Because modules will be reviewed without cost
>> OCA deserves an effort because many people have worked hard to get 
>> this reputation worldwide.
>> Regards,
>> Rafael
>> _______________________________________________
>> Mailing-List:
>> Post to:
>> Unsubscribe:
> --
> Maxime Chambreuil
> _______________________________________________
> Mailing-List:
> Post to:
> Unsubscribe:

Post to:



Joël Grand-Guillaume
Division Manager
Business Solutions

+41 21 619 10 28