Contributors mailing list archives
Re: Proposal for new workflow, incorporating "Optimistic Merging"by
I would like to say that I'm keen on optimistic merging.
Actually I'm not available enough to review all my code and I have some PR that are awaiting reviews and are not merged for "probably minor" reasons (mostly major reasons mayby ;-) ).
I feel really sad to not be able to achieve quality standards for being merged in OCA and it's a little frustrating for me all the more so as many new functions have been developped/ported.
So if it's a matter of vote, I vote for an optimistic merging.
For a little developper like me, having my code merge immediately (even in beta branch) in OCA repo is really like a big congratulation.
12, Rue Jean de la Bruyère
Mobile : 06 16 73 40 18
Tel : 09 72 45 77 55
Fax : 09 72 45 84 85
Le 07/06/2016 16:38, Maxime Chambreuil a écrit :<blockquote cite="mid:CACswP-COdb9_NN1ssAqn47Kd_VgXOXRvLk9JtwwHJB9vc4sRJg@mail.gmail.com" type="cite">MaximeDavid,I know the situation and change will not happen overnight. A transition period (maybe a year) would allow everyone to switch the input of their process from Github to Wheelhouse or any packages that will be made available in the future. They can keep/adapt their workflow, the idea is to change the location it start from to allow contributors to join, collaborate and innovate.And the transition period will not start tomorrow either. Maybe version 10 is a good moment.
Version 10 branches can also have optimistic merges and <9.0 still uses the current approach.Look at any other software: they are not deployed from the development environment. Why does Pypi, deb and rpm repositories exist? -- Maxime Chambreuil _______________________________________________ Mailing-List: http://odoo-community.org/groups/contributors-15Maxime, packages is your way of dealing with the code and deploying. Good for you. At Savoir-faire Linux this is not the approach taken, and you know that, you worked with us. It is not the meaning of OCA to choose how we deploy the code in our client projects. This is irrelevant. I'm sure each company has its distinct workflow to deploy projects. The github branches of OCA must be stable. David Dufresne, Consultant en logiciels libres Savoir-faire Linux Téléphone : 418-525-7354 #156 Cell : 418-271-0915 Ring ID : 9ac472765d298cc5de294b5765d0ccfaec48cbbf www.savoirfairelinux.com ISO 9001 et ISO 14001 ----- Original Message ----- From: "Maxime Chambreuil" <email@example.com> To: "contributors" <firstname.lastname@example.org> Sent: Tuesday, June 7, 2016 9:08:58 AM Subject: Re: Proposal for new workflow, incorporating "Optimistic Merging" I agree quality is important, but you won't lose it by deploying from packages. Packages will still have good quality. Keeping quality for packages will allow us to have collaboration and innovation (which comes with unstability) in Github repos. The gateway between unstable repository and stable packages is a manual release process. Le mar. 7 juin 2016 à 06:23, Rafael Blasco < email@example.com  > a écrit : Hi @ll, I'm not agree in an optimistic merging approach. This opinion depends of what do you think OCA is and OCA can be. OCA must ensure the quality of modules. This modules must be robust and never fail. OCA is a community that Customers take as reference of things well done, something that they can trust. Odoo is an ERP which fight with the big ones and implement Business processes worldwide. This is not CMS. Two examples: (1) You cannot trust in 99% of wordpress modules (2) In Odoo Apps store there are many many modules that are more a problem for the customer than a benefic (even-though you pay for it). When a customer trust in Odoo don't want to be optimistic, wants no risk for the investment. Customer must trust in OCA, Furthermore, in my experience, I quoted projects based in "what is done thanks of OCA" so Customer can afford project. This was absolutely a big mistake and I must said "we must develop everything". Because you don't expect to find such a bugs that you must refactor everything. This means that optimistic merging will create a feeling of " uncertainty OCA". Do we want more contributors? What is a contributor, someone who make PRs or someone who review PRs? Both. We need more reviewers too. Code Contributors in OCA must thanks what they will learn thanks to OCA and the experimented reviewers. They will significantly improve their professional skills. With optimistic merging which is the challenge? What will happens with the difference between contributors? The ones who make big efforts to make stable software, then ones who make quick software. Maybe it should be an "OCA Quality" and "OCA optimistic", meaning of their stamps will be very different and the we will ask customer: do you want to be optimistic and take a risk? or do you want to be sure about what your business software will do? Let's make last question. Why someone wants to put their modules to OCA? - Because they will have visibility --> Why OCA have more visibility? Because you will find a well done work. - Because modules will be reviewed without cost OCA deserves an effort because many people have worked hard to get this reputation worldwide. Regards, Rafael _______________________________________________ Mailing-List: http://odoo-community.org/groups/contributors-15  Post to: mailto: firstname.lastname@example.org  Unsubscribe: http://odoo-community.org/groups?unsubscribePost to: mailto:email@example.com Unsubscribe: http://odoo-community.org/groups?unsubscribe mailto:firstname.lastname@example.org  http://odoo-community.org/groups/contributors-15  mailto:email@example.com  http://odoo-community.org/groups?unsubscribe
Post to: mailto:firstname.lastname@example.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe--Maxime Chambreuil
Post to: mailto:email@example.com
ThinkOpen Solutions Portugal, Daniel Reis