November 2014 Summary
Minutes of Meeting
On 5th November 2014 at 2am NZDT (1pm 4th November UTC for those interested) the OCA Board held its monthly board meeting. These board meetings serve to update on OCA progress on targeted priorities, establish future priorities and discuss and vote on current issues.
The primary purpose of the November meeting was updates on work in progress. As there were no major decisions made, I’ve made this post a little less formal than usual and included topics that wouldn’t normally make it into this post.
Date: November the 4th, 1pm GMT
Location: Google Hangout
Participants :
-
Joël Grand-Guillaume, Camptocamp (C2C)
-
Luc Maurer, Camptocamp
-
Maxime Chambreuil, Savoir-faire Linux (SFL)
-
Stefan Rijnhart, Therp
-
Alexandre Fayolle, Camptocamp
-
Graeme Gellatly
Excused:
-
Eric Caudal, Elico Corporation
Late:
-
Nhomar Hernández, Vauxoo
-
Sébastien Beau, Akretion
IRC Channel #OCA
A special thanks to Paul Catinean for setting this up.
For those unfamiliar with IRC, it is like google on air hangouts without video, screen sharing, graphics and google. And voice, I forgot voice, no voice either. All text with special commands, kind of like the VI for messaging. If you want to give it a try, I gave it a go using the Chatzilla extension for Firefox. It is pretty good. Install it and type irc://freenode/OCA in your browser and you will get there. For those that use IRC please forgive my lame instructions.
The more technical board members pointed out that the OCA channel is for reviewers and contributors to the OCA to discuss OCA pull requests and other things that the asynchronous nature of GitHub often limits. It is not for general odoo or openerp support requests for which the #odoo or #openobject chan’s already exist. There are around 20 people on there at any given time.
Paul has also created a bot that trolls Github and sends messages about activities. (As a side note: AFAICT it gives the strong impression that Pedro Baeza does nearly everything for the OCA).
Project Structure & Management
Alexandre Fayolle updated the board that a number of projects were still without Project Leaders and that it was a time consuming exercise. Quite some time later when reviewing priorities the board unanimously resolved to close this task as we had gone far past the point of diminishing returns. There will be one last push to close out all these “startup” activities.
For a number of reasons, including;
-
Difficulty in filling some roles,
-
Misunderstandings experienced in what the different roles entail,
-
the often transient nature of project interest for contributors
Stefan Rijnhart proposed we review our structure and terminology. The scope is to review how we best manage our contributions against the realities of how open source projects develop over time. The board resolved that Stefan presents a report and recommendations, if any, for change at either the December or January board meeting.
In the meantime, if you are making a pull request, or have interest in being the central point of contact for a leaderless project please contact contribute@odoo-community.org.
The board was updated on ongoing work synchronizing our odoo instance with github and it appears this is all but ready and will be deployed shortly. The main benefit of interest to readers is the checking of signed CLA’s on pull requests.
Runbot
Alexandre updated the board on runbot progress. Apparently an average system load of 7.0 is quite high. There were over 700 databases. Alexandre put up the link and we bumped it up to 8 or so. The point here is that we either get more servers or reduce builds or improve runbot. Many of the builds are not required with tests being conducted in Travis.
Sandy Carter of Savoir-faire Linux and Alexandre Fayolle are looking at how we make this more manageable, as well as automating some tasks without spending more on servers. Some ideas presented including reviewers tagging those branches that needed building. In any case it works, but we need it to work better. I’ve not published the link as I am unsure what happens if we get to 10.
Accounting Workshop
The OCA sent a representative to the Accounting v9 workshop in Brussels. Unfortunately (for me) the report was in French and contained a few grammatical and spelling errors. This led to highly interesting Google Translate outcomes so I cannot report fully here. In any case, there were some discrepancies between our representatives understanding and Odoo’s official communications. Once we have those resolved a separate blog post will follow. Its focus will not so much be on what Odoo is doing for which there is mountains of virtual paper, but where the community must assist and react in the areas receiving less attention and its potential impacts on our existing projects.
Official Odoo specifications are here.
MRP
Now that the list of requirements is stable enough, it is now time to:
-
propose your existing module for each requirement
-
test those suggested module against the requirement
-
select the best one to fit in the overall project
To achieve that, the OCA invite any contributor to fill in this pad: http://pad.odoo.com/p/mrp-modules
Contributing to the OCA
I’m going to diverge a little bit from the official discussion here, and write a personal piece, but it is not the first board meeting this has occurred and it won’t be the last. I write it this way because the names and projects don’t matter, it is the underlying principles that count.
Firstly, often an organisation or an individual who has created code and kept it hidden for a few years for whatever reason comes to us and offers their code. There is no judgement here. We get it and we understand.
But what we can’t do is offer any special assistance. It is not the existing OCA codebases issue that the new work is only now being proposed. Anyone who has experienced porting their code to OCA repositories or any other public repositories will understand. Porting and integrating previously private code into an existing public structure is a massive job and best done by the contributor.
-
Where does it fit?
-
What is duplicated?
-
What needs refactoring?
-
Do I need new dependencies?
-
Do I have intricate dependencies?
-
Do I need to split modules?
-
Is there customer specific things that need generalising out?
-
And a whole lot more
The contributor needs to fit with the existing OCA repositories and make pull requests as appropriate. The feedback on individual pull requests will help answer those questions. The peer review process, continuous integration and OCA standards will help refine and improve contributions. Asking the OCA board to expedite a process for 20, 50, 100 or even 500 modules is counter to those objectives. We want your contributions, really we do, but ultimately to gain credibility and acceptance the standard processes are best, in small chunks.
We also have the opposite problem. People come to us with brand new code and want to contribute it, but it doesn’t fit into any existing project. So we are left with a tough choice. Do we make a team of 1? There has never been unanimous board agreement on this topic or for any individual request. We know we need to do something here, but quite what that is still up for debate. I just wish it wasn’t always at 4am in the morning. However the current prevailing attitude of the board amounts to this:
-
Who are we to tell someone we don’t want their contribution?
-
If they are willing to follow OCA rules (e.g. 2 reviews before merge, quality standards) how can we even say no?
If it eventuates that the project (or any project for that matter) is ignoring these rules we will reevaluate its inclusion. I hope the above illustrates the natural tension that exists in contributing to the OCA. Enter early and you need to quickly develop your teams and support structures, enter late and you must be highly sympathetic to the existing codebase. But regardless of when you decide it is appropriate to contribute, the board does unanimously agree that the existing processes are the best we have right now and they need to be complied with.
There are no special exceptions at either end, but equally, at least for now there are no exclusions either. We want valuable contributions and valued contributors and generally we always fall on the side of the contributor. But it is only through contributors adhering to OCA processes that we are able to maintain such a permissive stance. The board thanks all our contributors for this.
Regarding contribution in general, it may be purely coincidence, but since we switched over to the twitter bot notifying about OCA Review day closed issues and PR’s have jumped quite remarkably.
I also reported back about what I’d found about how we can understand and better recognize our contributors. There were two promising tools.
-
http://www.githubarchive.org
-
gitribution from the Mozilla project.
As contribution and participation rates have increased then perhaps this is no longer needed. I still have it as a low priority to investigate further. If anyone is really excited by this and wants to have a go at mining the githubarchive data using google big query in particular and letting me know what we might be able to do then please do.
Outstanding Issues
We had a quick review of the outstanding issues sent to our support and contribute emails. For the most part they fall into the “teething problems” category with our migration to an Odoo instance. Access rights, incorrect mailing list setup that kind of thing. There are a very few others left that require extra attention, such as convention suggestions. The board resolved to solve the technical issues this month and have already made significant progress. For those who have been waiting a while please accept our apologies. We get a lot of emails to these addresses and they take dedicated time to deal with.
