Contributors mailing list archives
Re: OCA Release Process and Module Lifecycleby
Sunflower IT, Tom Blauwendraat
What I think I am reading, in summary, is that:
- OCA will stop requiring 2 reviews for each and every merge by default
- Instead, 2 positive reviews will mean that the module will get 'OCA certified', although the process for this still has to be developed
- Repository owners will be able to set their own rules with regards to OCA policy
I think this addresses the current problem of many unreviewed PR's, what I am afraid of is that breaking code will get merged in, and that OCA modules will lose their reputation as "the modules that always install without problems". On the other hand, if you want that, you could use only "certified" modules.
All in all I think this step could work out well for OCA, if the details of the process are worked out more clearly, so I'd say +1, move forward to a description of a concrete implementation for this plan. Then there is something more concrete to give feedback on, like how to arrive at certified status, how to properly accept or refuse repository owners, etc.
On Mon, Feb 12, 2018 at 3:17 PM, Jean-Charles Drubay <firstname.lastname@example.org> wrote:
Thanks for breaking the ice Moises :)+1On Feb 12, 2018 9:02 PM, "Moises Lopez" <email@example.com> wrote:+1On Sat, Feb 10, 2018 at 3:16 PM Maxime Chambreuil <mchambreuil@opensourceintegra
tors.com> wrote:Dear Contributors,I just reviewed and accepted most of the contributions in the Release Process and Module Life Cycle document:At this point, I want to make sure we haven't forgotten any valuable input and we all agree on the principles explained in the document.Everything in there may not be implemented on day 1 considering the current features available in our infrastructure, but that's at least a direction we would like to go.Do we agree? Can we move on to the next steps and define a plan for a first implementation?--