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
ClosingAp Open Source Integrators Europe, LDA, Daniel Reis
- 18/06/2016 00:24:02

Hello again,

There were some relevant objections to the proposed workflow.
I took some time to work on them, and to contact Pieter Hintjens, the OM proponent, for advice about our case.

It was mentioned the OM is suitable patches, but not for new module proposals.
Pieter confirmed this. OM expects small changesets that are easier to review.
"Optimistic" just means that we should not merge them only if something clearly wrong is found.
Pieter also said that master should always build. That's the equivalent for us to always having CI green,

But or problem is exactly with larger new module PRs
AFAICT small PRs are not very frequent, and in most cases are already fast merges.

So how does Pieter's OM handle non trivial feature requests for ZeroMQ?
They create a new repo and collaborate there, until a mature enough solution is ready to merge into master.
But wait - that's the fork workflow we already use: fork the repo, develop the feature there, ask for opinions, and when ready ask for pre-merge reviews.

My conclusion is that the current workflow is appropriate, maybe we only need to foster the practice of having several people collaborating with commits in the same WIP PR.

Another suggestion that could improve PR cycle time is to block PRs only if something is wrong:
In the cases where reviewers something can be improved, made more efficient, or more complete, that should be left to a second PR, so that the original one can get merged ASAP.  Similarly for some "harder to get right" features, an option might be to remove them from the original PR and having them added in a following PR.

A case that was also surfaced in the discussion was using small repos (some eventually with a single module).
This idea is not a requirement for an OM strategy, but is relevant to creating WIP workspaces where new features are matured until ready to be released as stable. Examples like Jordi's Project Earned Value Management and Elico's Business Requirements come to mind.

Until now I haven't been very sympathetic about the small repo case, since it brings coordination issues that haven't been answered yet
I gave them a lot of thought, and I believe to have found an incremental solution to the OCA workflow support for these small repos.
And this in a way that is complementary to how we work today. It is evolutionary rather than revolutionary, so we could start using it immediately, as soon as we agree on the details.
However I prefer to draft that specific proposal in a different thread.


Best regards
Daniel

Reference