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
Open Architects Consulting, Houssine BAKKALI
- 06/06/2016 22:16:40
If you allows me... going for the explained OM wouldn't solve the "problem"... For the PR that still pending and that i've followed several stay pending because some reviewers are sometimes a bit too picky for change that wouldn't make any difference and that could also be a factor for contributor to give up.

I'm not blaming but just saying... Reviewers are doing a great job and they just have to find the good balance...

2016-06-06 19:38 GMT+02:00 Maxime Chambreuil <maxime.chambreuil@gmail.com>:
Hello,

I think we should first agree on where to install from. We should move our current and new deployments from Github to use packages from http://wheelhouse.odoo-community.org.

Once the development environment is disconnected from the production ones, then we can have the approach we want on Github and try different release process and repo conf. Rolling out different ones in the same time will allow us to benchmark them, see which one works in which situation.

The process I would like to experiment is:
  • Document new features and new contributions in Github issues
  • Optimistic merges on 7.0, 8.0 and 9.0 branches
  • Freeze branches before a release to make CI green
  • Update setup directory for mature modules to trigger repackaging and tag the branch with the date ("20160606")

I would like to encourage every new and current contributors to contact the PSC on the mailing list or with a GH issue to announce their intention to work on something. Figuring out things on a PR is too late and increases the chance to get contributions refused, frustrating the contributor and the PSC member.

My 2 cents.


Le lun. 6 juin 2016 à 12:09, Moises Lopez <moylop260@vauxoo.com> a écrit :
I'm still not sure how to do it, because requires a cleaning step and many times is harder to clean.

2016-06-06 10:38 GMT-05:00 Jean-Marc Dupont <jmd@6it.fr>:
Yes, go for it !

We have our first contribution waiting for approval 
;-)



Jean-Marc DUPONT 

Agence Web, e-Commerce et Systèmes d'entreprise 

68, rue du Refuge - 84200 Carpentras

T. 06.24.91.02.03  -  04 84 25 17 94

Éditeur de la marque Provenc.io

1° marque e-Commerce 100% Provence





2016-06-06 17:07 GMT+02:00 Joël Grand-Guillaume <joel.grandguillaume@camptocamp.com>:
Hi all,


Thanks for your feedback here. I'm still not sure how to do it, but I'm sure we need to change the way it's done currently. Too much PR left alone, too much contributors frustrated during their first contact with OCA and reviews.

I'm guessing this will be the challenge of the next OCA board to solve and improve this situation. We should not forget that this is really a "good" problem we face, it shows that OCA has a real success !

IMO, the two main goals of the new process must be:
 
 * for a great contributor experience first
 * to optimize maintainer time second

I also agree that some basic rules must be asked from contributors in the first place (as Ronald pointed out). But I'm convinced we can achieve this with Optimistic merging if proper tools /process are in place.

Regards,

Joël




On Mon, Jun 6, 2016 at 2:08 PM, <Bidoul@pad.odoo-community.org> wrote:
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

_______________________________________________
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

--


camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

Joël Grand-Guillaume
Division Manager


_______________________________________________
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




--
Moisés López Calderón
Vauxoo - OpenERP's Gold Partner
Mobile: (+521) 477-752-22-30
Office: (+52) 477-773-33-46
web: http://www.vauxoo.com
twitter: @vauxoo
           @moylop260           

_______________________________________________
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


Reference