> We have time to iterate this though, not like I want to ship 0.9.0
> tomorrow!
>
Maybe we should do a poll to see how many of our users are using released
versions of libMesh. I would say it is nearly zero. I know of over a
hundred who are exclusively using the SVN version of libMesh: our users.
With that in mind, we should take steps all along the way that allow the
SVN version of libMesh to be used. Stating that "they can download
nightlies" or "we have time until 0.9.0" doesn't do justice to the reality
that many people are using the library right out of the repo.
There seems to be a trend here lately where libMesh devs are continuing to
push for users to not use the repo version of libMesh. This is exactly the
wrong direction... and it goes against what the rest of the scientific
library community is moving toward.
With MOOSE we don't have releases _at all_. All of our users use the
"trunk" version of our code. Our development process is called Continuous
Integration (CI: http://en.wikipedia.org/wiki/Continuous_integration ). It
has been working beautifully for over four years. In this development
mode, every change to MOOSE is immediately integrated with all of our
user's codes. No one is ever "out of sync" and there is no "integration"
or "upgrading" ever to be done. This is all powered through a robust and
thorough testing system that ensures that every application (of which there
are now 20+) built using MOOSE continues to function through every change
to MOOSE.
We recently (like two weeks ago) had an external software quality audit
where a team of people came in and examined every part of our software
development cycle. Not only did we pass with flying colors and were
granted NQA1 status (which means MOOSE can be used to create software that
is used is the design of nuclear reactors) but the software quality team
was blown away by the continuous development path we use.
If you want to do some reading on the use of continuous integration (or
nearly continuous) in scientific software development you can look at some
of the papers by Roscoe Bartlett (
http://www.ornl.gov/~8vt/publications.html ). For instance:
http://www.ornl.gov/~8vt/CSE_SoftwareIntegration_Strategies.pdf
http://www.ornl.gov/~8vt/TribitsLifecycleModel_eScience_2012.pdf
I'm not advocating everything he says... but the core ideas of "integrate
early and often" are important in scientific software development...
especially when that development entails intimately tying your code to a
software framework.
With these ideas in mind we should be striving to make the repo version of
libMesh as accessible and simple to deal with as possible. We should
encourage our users to use it. We should encourage our users to update
_daily_ and we should work to make sure that what we do in the repo is not
disruptive to that.
I am straight up frustrated with the state of the repo at the moment.
Derek
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
