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 to support small repos into the current OCA workflow

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

Avatar

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

by
ClosingAp Open Source Integrators Europe, LDA, Daniel Reis
- 20/06/2016 21:09:56
I don't really see the point. Optimistic merges are as valid and guideline enforced as all others.
The only difference is that you should merge as soon as the work is good enough, even if it can still be improved.

A better question is how do I now the improvements that should be added next, following the review feedback.
Until now I have been asking people to write them in the README. But I get to think that it contributes to slow down the PR duration. Maybe it's best to add it to the PR top comment, or create a separate PR/Issue for that.

--
Daniel

No dia 20/06/2016, às 08:53, Rafael Blasco <rblasco@rbnpro.com> escreveu:

Hi,

How will we know which module has been merged optimistic and which one not? Like a label or a field in OpenERP.py

Thanks

El 19/6/2016 11:38, "Daniel Reis" <dgreis@sapo.pt> escribió:

Thank you Luis,

OCA uses the simpler Feature Branch workflow, where we have a single stable branch.
The GitFlow ellaborates on this separating this reference branch into three: develop, release and master.

There is a nice comparison at the Atlassian website: 
https://www.atlassian.com/git/tutorials/comparing-workflows

In that perspective, I can see that my initial proposal ends up being something in between, using two branches: develop and release/master.
But even that "simplified Gitflow" faces an issue:

Contributions to the OCA are mostly opportunistic.
We don't have a dedicated team, systematically working on the codebase.
Instead people share code they find that can be useful to others.
But then they need to address first their bill-paying customers, and often can't find the time or motivation to improve the code according to the review feedback.

That's the main reason why PRs are stalled - lack of follow up from the author.
So a "develop" branch would quickly become bloated with zombie code.
With Feature Branch, that code just hangs in a separate branch, and can eventually picked up by someone later.


The point with my reviewed proposal is to instead leverage collaboration on feature branches:
- have them visible (this is achieved with open PRs), and
- foster incremental collaboration in those feature branches, that today happens seldom.

For the second point, some action items could be:
- preferring breaking up feature additions into multiple PRs (instead of requesting the authors to expand the current PR).
- providing easy documentation on how to make a PR on a PR
- eventually providing some git wrapper to make it easier to fetch PR branches


Regards

/DR


Citando Luis Felipe Miléo <mileo@kmee.com.br>:

Hi,
 
+1
 
There is a tool that with some adaption can even automate the process merging and creating pull requests in OCA.

https://datasift.github.io/gitflow/
 
Available subcommands are:
   init      Initialize a new git repo with support for the branching model.
   feature   Manage your feature branches.
   release   Manage your release branches.
   hotfix    Manage your hotfix branches.
   push      Push the changes from your current branch (plus any new tags) back upstream.
   pull      Pull upstream changes down into your master, develop, and current branches.
   update    Pull upstream changes down into your master and develop branches.
   version   Shows version information.

- When a developer creates a new feature / hotfix a new branch is created on your fork. This helps other contributors know that there is someone working in a particular activity and interact with it;
- When the feature is completed is made an automatic merge the branch beta (or Develop);
- When a hotfix is ​​finished is made a merge both branch beta as the master (8.0 / 9.0);
 
Best Regards.
 
- Luis Felipe Miléo

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


Reference