Contributors mailing list archives
Re: OCA Dev & Deploy Tooling PSCby
David Arnold BA HSG / Analista
315 304 13 68/ firstname.lastname@example.org
devCO - empresa de consultoría de sistemas (en fundación)
This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. devCO is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company.
On Wednesday, 21 October 2015, David Arnold <email@example.com> wrote:
Thank you Joel,
Actually, I read "Tools Maintainer" = Tools for People maintaining the OCA. If it would have been Kickstarter-Tools I would have understood upfront.
I will do as you said. And propose a "Dev & Deploy Convergance Initiative" instead.
DavidExactly the definition...We the one which mantain OCA repository are the ones that actually add and make new modules and new features. Then I think we must create tools for the people that actually contribute not the one that is only willing to make development for themselves..We the developers behind OCA repositories will be the first benefied people with any tool developed to help to program fast and easiest, that's the place to improve.If somebody is new and want to start from scratch the first thing to read is "how to mantain and make better code" if this is not the first place where somebody new read to, may be he/she is not somebody that is really willing to program to share, or simply do not have the technical level yet, there is where the documentation will be important.If it is a functional guy, then the run it link is for them, don't worry about deploy anything...I can not see another market where we should add "development tools".Regards.JoëlKeep contributing,Thanks for your interest,If you want to suggest a new project under a PCS responsibility, please write in the contribute@ mailing list to ask for.Based on meritocracy current PCS members are in charge of electing new members here and also free to accept new repository under their responsibilities ( as for the current discussion, may be two more : Buildout and Docker).Anyone wanting to join this PCS is welcome to write on this mailing list :firstname.lastname@example.orgDear contributors,For now, the current PCS called "Tools Maintainers" (on github) is in charge of such a topic (Dev & Deploy Tooling PSC).On Wed, Oct 21, 2015 at 11:08 AM, Oleg Kuryan <email@example.com> wrote:
Looking at what you are saying in mailing list I see that you have a great technical knowledge and passion that is must have to move things forward. So my vote is is for you to design plan for this, so everybody interested can discuss it.
And I'm interested person (unfortunately not to much time, but try to do that as much as I can).
Main points I would like to point to you and to all reading this mail thread - tooling is not the most important to be defined first. I think that we need to define goal we are trying to achieve.
My opinion is:
1) Now Odoo world have more developers rather than consultants.
2) Obviously developers do a great job in adding new modules and features, but that is combination of developers and functional people who really will do business and make project successful
3) Next thing is that obviously there are a lot of modules(not only in OCA) that add lots of value. There is already great tool provided by Markus from from initOs that allows to find modules. It is first step, but not enough.
4) Next step is to allow functional consultants to easily create environment on their local machine, to quickly code module that will have ONLY dependencies to github Odoo modules (and not only OCA) and test combination of those modules.
5) Usually that is because tools like runbot and etc. do not allow to combine modules together and test them in combination. Not saying that runbot is useless. It closing good what it should be used for, but again - not enough.
6) Now the reality is that consultants in my company learned how to install modules on their local computer for testing purposes. Also we already have technical means internally based on Jenkins that simplify this process allowing to install on server. But still quick installation and testing locally is usually case that happens and obviously that will be always the case.
So conclusion is that we need to be focused not on Developers specific tools (scripts, plugins). But to be focused on ready solutions that is usable not only by developers, but also by not so technical people (like consultants).
I will fully support the idea and contribute to it if we go this direction.Hi,
I want to suggest and solicit the creation of OCA Dev & Deploy Tooling PSC.
I want to take responsibility in the PSC and ensure thereby a technical and well-informed discussion.
I further want promote convergence and best practices in the OCA on this topic, keeping an eye on the needs of newcomers.
If this finds approval, I would like to convocate an open design process on the creation / convergence of a comprehensive set of base docker images, that are suitable for production and Dev and compatible with existing (anybox) as well as embrace new tooling.
In a next step, I would like to focus on the Dev sugar, because this is where there is a real perceived lack of coolness ;) in the existent tooling.
In some future I would like to open up discussion about possible deployment techniques. However, I feel this is many steps ahead still & with anybox, we have a "running horse". ("Never change a running horse")
I would like to have anyone especially interested in this topic and with sufficient technical knowledge in the field to express his interest in taking responsibility in the PSC.
I'm furthermore committed to aport to a better OCA culture. (I admit, I'm not happy with the current state.)