1. Mailing Lists
  2. Contributors
  3. Re: Proposal for new workflow, incorporating "Optimistic Merging"

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

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

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

Avatar

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

by
redCOR AG, Robert Rottermann
- 07/06/2016 18:47:53
I am not yet a contributor to OCA.. (I would like to have found a way to become one tough)
But I have been a contributor to an other vivid toolset: Plone/Zope for years.

there the workflow was/is something like this:
- who ever has signed a contributor agreement got commit permission (the system was subversion based in my time)
- there where sub-packages for which a maintainer was responsible.
- the code was heavily unit-tested
- people where only allowed to check in stuff that passed all  unit tests
- if somebody's check in broke  something he was quickly yelled at and had to back out his/her check ins
- from time to time a "release" was made for which a list of "good" releases was maintained. The "maintainers" where responsible for this step.

this process allowed for a very vivid and active community that could easily contribute.
The code was well tested and very solid.

I believe we should try to find a way along this lines.
The actual situation is plain bad I think.
It actively discourages contributers and blocks good stuff waiting to be evaluated
EVERYONE of us should be able to check the code.

But EVERYONE needs a handle to judge what code is good and stable.

So it must be EASY (according to well defined rules) to contribute.
And we bust be able to tag  STABLE versions.

robert

On 07.06.2016 16:23, Daniel Reis wrote:
<blockquote cite="mid:20160607151408.Horde.e3caqV_B9lvJFlhlOdp3bmy@mail.sapo.pt" type="cite">

Several people are raising the loss of quality concern:

> 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 ?

I must repeat:

Reducing the quality of the OCA published modules is *not* under discussion.
The discussion is about a new process to reach publishable modules.
Consider it a pre-requisite for any proposed process.
My proposal honors it, and do does the release-tagging proposal.

The quality issue is a false question.
Can we move on?
 

/DR


Citando bruno@joliveau.com:

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,

Thanks,

Bruno JOLIVEAU

ERP Project Director @ Savoir Faire Linux
More links : bruno.joliveau.com

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 
> <rafael.blasco@tecnativa.com> 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: http://odoo-community.org/groups/contributors-15
>> Post to: mailto:contributors@odoo-community.org
>> Unsubscribe: http://odoo-community.org/groups?unsubscribe
> 
> --
> 
> Maxime Chambreuil
> 
> _______________________________________________
> Mailing-List: http://odoo-community.org/groups/contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: http://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


 

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


Reference