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
Acsone SA/NV, Stéphane Bidoul
- 06/06/2016 14:04:25
Hi,

Thanks Daniel for bringing this to the list.

My thinking goes along the following lines:
- PR towards the main branch
- formal releases marking stable versions
- evolving towards a process that allows optimistic merging (ie Hintjens' C4 http://rfc.zeromq.org/spec:22/ or similar)

This approach, as well as Daniel's, have in common to increase the burden and responsibility 
on maintainers who do the releases. This is, IMHO, a necessary step, though.

To make this manageable, I envision:
- smaller repositories
- each repo containing a very cohesive set of modules (yes that may mean some repos with only one module, I now think we can manage that)
- all modules in a repo following the same release cycle
- each repo with clearly identified maintainers who take full ownership on release management
- such repos under the responsibility of PSC who help allocating new contributions to repositories (with the approval and endorsement of repo maintainers, of course), and ensure all maintainers respect the rules
- often a new contribution will need a new repository, that is fine as long as the contributor commits to take ownership and abide by OCA rules

It's quite a change but I think it's manageable. Perhaps with some small evolution in Q&A bots.

I'm convinced smaller repositories have many advantages, mostly deriving from a clearer and stronger ownership of modules.
- patches to existing modules will be reviewed sooner because owners of repos will feel more responsibility to do it sooner than later
- new modules or set of modules can be accepted in their own repo provided the contributor takes ownership and agrees to maintain it according to OCA rules, the repo then lives it's own live according to classical FLOSS evolutionary laws.

Food for thought...

Best regards,

-sbi

On Mon, Jun 6, 2016 at 12:52 PM, Leonardo Pistone <lpistone@gmail.com> wrote:
I agree with the general idea, thanks! I have some specific remarks though.

What happens often in open source is that merges are made to a
mainline branch (this can be called trunk, master, develop, next...).
Then maintainers make a releases with some extra review and testing.
(a release is an annotated git tag, optionally with merge to a stable
branch). We should then use those releases in our projects instead of
git hashes as we do now. If we need a bugfix, we should try to make
the effort to make a release (otherwise they are almost worthless).

I think this mainline + releases strategy would be good for us as well.

To avoid doubling the burden on maintainers, we do optimistic merges +
releases. The merges could be (almost) automatic after a few days if
the build is green and no-one blocked the PR explicitly.

On the other hand I would block if unsure if that is the right branch,
and in general I would try to avoid to force maintainers to
cherry-pick/filter-branch at every release. This is painful,
error-prone, creates conflicts etc. The goal should be that all green
modules that have not been blocked should be released, eventually with
a bit of extra work and review when merging. Exclusion (so
filter-branch and friends) should be the exception IMO.

On Mon, Jun 6, 2016 at 12:23 PM, Eric Caudal <eric.caudal@elico-corp.com> wrote:
> Stable branch (current one) will keep the PM strategy to keep quality
> standards.
>
> --
> Eric Caudal [Founder and CEO]
> Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37
> (Office)
> Elico Shanghai (Hong Kong/Shenzhen/Singapore) Odoo Gold Partner, best Odoo
> Partner 2014 for APAC
> On 06/06/2016 06:08 PM, Nhomar Hernandez wrote:
> 
 cite="mid:CAKtu5Y4JDZyOzGngJrWY9rtXEAWrm4yeK8JtBKjb4fiSs6KVjg@mail.gmail.com"
> type="cite">We have projects where PM is mandatory and others where OM is
> mandatory, can we have different strategies?
>
>
> _______________________________________________
> 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