Hi everyone! First, on the original topic of this thread: I think the new repo is fine, it may be a useful alternative to consider placing such things in a utilities/ directory on opm-core instead to reduce the number of repositories though.
Second, about gentoo, development platforms etc.: all developers have their preferences, and we basically have scratched our own backs when it comes to platform/distro support. I make sure it works for me (Mac OS X), others make sure it works on SUSE, Ubuntu, RHEL etc. There is as far as I can tell only one compromise made (in the sense of restricting the developers) for compatibility, and that is that we should support gcc 4.4 (which means that certain C++11 features are not to be used for example). I see that gentoo is making some people very enthusiastic, and may try it in the future, but platform support will come from people who actually use it of course. When it comes to compilers, I use a recent clang, so do some others. I know people are using gcc versions from 4.4 to 4.9. So I think our platform support is broad enough from a developer's point of view. Third, about user friendliness and support: this year, work on such things (in particular creating a new proper release) has taken a back seat to completing the work on the fully implicit black-oil simulator (opm-autodiff's sim_fibo_ad as it is currently named). This is quite unfortunate, but it is both a question of resources and priorities, and also about not advertising a release until the new things in it are complete. The second point is probably a bit controversial: it is against the 'release early, release often' mantra that is often considered desirable. It is a bit psychologically motivated, I think: if I feel that the complete version is just around the corner, I'd like to wait just a little bit before releasing. Of course that may turn into a problem when things take longer than expected, as they often do (and did in this case as well). Part of the user-facing complexity is the existence of several modules and their non-trivial dependence relations. Also the fact that different modules may require different third-party libraries, some of which may be optional. There will always be a tension between wanting everything to be in one big module for simplicity and wanting each piece to be as independent from others as possible. My current views are: - There are currently too many modules, and it is bad that opm-core is not the root of the tree. Suggestion: combine opm-parser and opm-core into opm-core. - We do not want everything in one module, we should have a fairly low threshold for adding a new module with new functionality. But we should allow the core (or a few modules close to it) to grow to include such things as they mature. - Adding third party dependencies (such as Eigen) to the core is acceptable if it is easy to satisfy this prerequisite on the most important platforms (Ubuntu and RHEL in my mind), easy meaning 'can be done with a maximum of 2 commands'. So it should be no more complicated than adding a PPA and apt-get. And it should not be hard (requiring manual tweaking) on any of the platforms we support or work on (I'd like to get rid of SuperLU usage for this reason). A new code having a new third-party dependency is often a good reason for putting it in its own module. - Using branches instead of repos seems very alien to me, I do not think it brings much benefit, but it does require more attention and care from users and developers. If I want to use code together that resides in two different branches, I do not see a simple way to do this, other than having multiple working copies of the repositorym each checked out to a different branch. - As everyone else, I agree that the current situation with the build-system being duplicated everywhere is not good. I do not think we have reached a consensus about how to replace it though. I'd like for all of it to be in opm-core only, and other modules only having a way to find opm-core, and adding their own file lists etc. Atgeirr Flø Rasmussen _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
