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
Therp, Ronald Portier
- 06/06/2016 12:45:27 
Hello,

I am much in favour of keeping it as is.

The rather strict OCA rules teaches every contributor quickly the proper
way to do things. The rules are well documented and easy to understand.

I would not trust the contributions from people not able to follow these
rules.

Of course people can make mistakes. I make a lot myself. But then I am
corrected and learn.

Without these corrections, there would be no progress in skills or
knowledge.

Kind regards,

Ronald


Op 06-06-16 om 11:37 schreef Daniel Reis:
> Hello all,
> 
> 
> Some discussion has been going on, to try to make OCA friendlier to new
> contributors.
> Have a peek at:
> https://twitter.com/jgrandguillaume/status/735738547118825475
> 
> The "Optimistic Merging" strategy that can make that possible:
> Instead of requesting the contributor to have perfect code,
> contributions are quickly merged so that others can improve them ("crowd
> patching").
> This provides a more satisfying experience to contributors,
> and provides some "low hanging fruit" for newcomers, such as simple code
> style fixes.
> 
> "Optimistic Merging" has some research backing it.
> Learn more about it here:
> - http://hintjens.com/blog:106
> - https://www.youtube.com/watch?v=O8CbzKREAj4
> 
> 
> Based on these ideas, I would like to draft a proposal.
> 
> The outline of the new OCA workflow would be like this:
> 
> 1) Pull Request are made for a "beta" branch. E.g. "9.0-beta".
> 2) Pull Request has flash code review and a fast merge
> 3) Pull Request diff will still be available for further
> discussion/collaboration
> 4) Imperfect code merged is "crowd patched" until suitable for stable
> release
> 5) Pull Requests made for stable branch, e.g. "9.0", extracting relevant
> commits form the beta branch.
> 6) Full code review is made, and green CI required, as per current
> standards.
> 7) Fixes to the Pull Request for stable should then be also merged into
> the beta branch.
> 
> 
> Some details:
> 
> Beta branches are initially branched from the stable ones.
> Pull Requests should target beta branches.
> These are merged with an Optimistic Merge policy.
> Merging would be expected to happen fast,
> and PR comments would mostly be for discussion, rather than validating
> the merge.
> Rarely a PR should be blocked - it must be obviously toxic, or
> conflicting with other PRs.
> MQT needs some adaptations to be useful in this scenario, but that's not
> a real issue, and is a separate discussion.
> 
> The beta branches are expected to have frequent improvements from
> multiple contributors.
> They are not guaranteed to be correct nor API stable.
> Module versions are not bumped.
> People using code from it should be careful pinning Git revisions.
> 
> Module stable releases should be extracted from the beta branch and
> proposed to stable version branches.
> Similarly to ports between major versions, this has its details in order
> to keep history.
> It would usually be done by more experienced contributors, and we can
> have tools to make it easier.
> Module versions should be bumped in the process.
> 
> 
> Would to hear your comments and suggestions.
> 
> Best regards
> Daniel Reis
> 
>  
> 
> 
> 
>  
> 
> _______________________________________________
> Mailing-List: http://odoo-community.org/groups/contributors-15
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: http://odoo-community.org/groups?unsubscribe
>

Reference