@alistairsellar @bouweandela @bsolino @jvegasbsc @remi-kazeroni @sloosvel @valeriupredoi @zklaus
There was a question from @alistairsellar about the possibility of having an observer in the Tech Lead team meetings. This question quickly broadened into a discussion about the openness of the meetings.
To follow the ESMValTool philosophy of being open by default, it was decided to make the meetings open to everybody regardless of role. Only members of the Tech Lead team will have a vote in the decisions but all opinions are welcome. Meetings will be publicly announced, but they will not be as advertised as the monthly meetings, as this are not meant to be an entry point to the community.
Agendas and minutes will be kept in a GitHub project (this one) so everybody can check past and future meeting contents.
@alistairsellar reports that MetOffice lawyers strongly recommends that the ESMValTool project adopts a contributor license agreement. This recommendation is meant to protect the project from lawsuits from contributors, in particular to avoid contributors suing the consortium for distributing code without the rights to do so.
Final decision will probably be made at a higher level, but anyway the opinion of the tech lead team on this matter is requested.
First issue here is that no member here is expert enough to have a strong opinion and that the position of other institutes on it is not clear.
The second concern is that we may not be able to get all past contributors to sign a CLA. This was already expected by MetOffice lawyers and they stressed that having only some parts of the code under CLA is still better than none.
Another concern expressed by the tech lead team is that some other projects have abused CLAs to close former open source projects and that this, along with an extra bureaucratic burden, will be an issue. In general, we need to consider carefully its advantages against its potential to drive off some contributors. For a good article against the adoption of CLAs, see: https://ben.balter.com/2018/01/02/why-you-probably-shouldnt-add-a-cla-to-your-open-source-project/
It is also remarked that the GitHub terms of service can give us some of the protection that we may get from the CLA. We will need the opinion of the lawyers on this, though See:
From now on, ESMValCore will be first released as a release candidate to allow us to fix whatever bugs appear when testing ESMValTool. Both public releases will be done at the same time.
Julia support is becoming a problem for little gain, as we are still having only one recipe using it. The main issue is that it is not easy to package, as it has its own environment management and expects all codes to use their own.
The other reason to consider dropping support for it is that it is still not gaining traction among scientists, mostly because it lacks lots of libraries that are commonplace in Python or R, so any potential gains from switching are offset for the extra amount of work required to do nearly everything from scratch.
In order to keep the support but reduce the burden, we will experiment with replacing the direct download of Julia binaries with its conda package and see if that improves the situation.
@zklaus asked to remove conda build from our tests, as this is now done in conda-forge directly. We agreed to reevaluate our testing infrastructure to avoid redundancies.