On 11/28/2014 11:04 AM, Anders Logg wrote:
Hi all,

I visited Simula this week and yesterday we had a very informal
"developers meeting". Here are some preliminary notes from the
meeting. Since not everyone was there (or even knew about the
meeting), let's continue the discussion here on the mailing list.

For the future, it might be good to arrange regular meetings via
Google Hangout or similar.

Here are the issues we discussed:

* Release

We haven't made a release in a long time and 1.5 is overdue. My view
is that we can make a release whenever the buildbots are green unless
we know something important will soon be fixed. (If it gets fixed
later, we can always make a new release then.) I also think we should
aim for a predictable release schedule. The proposed release schedule
is twice per year: 15 jun + 15 dec. These are natural dates (end of
term) and it works fine with the Ubuntu release schedule.

We get started right away with a release of 1.5 on 15 dec.

Note that this does not mean we can't make a release any other time we
feel like it, just that we get at least two releases per year on
predictable dates.

Agree. I would also very much like to see a predictable schedule,
but have little preference re: dates.

I would also suggest that we appoint a "release manager", who is twice
a year responsible for reminding everyone that a release is
approaching and it's time to fix bugs... Any volunteers? Martin?
Chris?

Or Johannes?

* Tests

We discussed the tests in DOLFIN taking a long time to run. With the
new work on pytest, the quicktest is actually pretty quick (after JIT)
so this may no longer be a big issue, but we should make further
effort to reduce the runtime of the tests.

* Documentation

The documented demos need to be revised and improved, and some kind of
categorization is needed. Right now they are presented in a "random"
(alphabetical) order. The suggestion is to add tags to all demos (in
some formatted comment) so that a Python script can generate a list
for the web page with demos for different categories, like PDE, mesh,
boundary condition, meshfunction, parallel, parameters etc etc. Note
that each demo can have several tags. Other useful tags that Garth
suggested are "beginner", "intermediate", "advanced".

Agree! Would also be great to have some user input on this,
say from students taking a course using FEniCS, or any
non-core developer reading this list ...

* Installation

We have several ways to install FEniCS but the web page does not
reflect all possible options, and perhaps misses out completely on
the best options. The suggestion is that Johannes will (again) post
instructions for how to build FEniCS with hashdist. Then we all commit
to give hashdist a try and think about how we can smooth any sharp
corners. If this works out well, hashdist would be a candidate for
being listed as a/the official installation process for FEniCS.

* Recipes / howto

There is need for a collection of user recipes for doing stuff with
FEniCS. This can be both "How to build FEniCS on Mac using HomeBrew"
or "How to set initial data for a mixed system". The suggestion is
here to use the FEniCS QA and encourage everyone to submit their best
recipes and tagging this by either "recipe" or "howto". (We can vote
on what is the best tag.) Using the QA means recipes can be voted up
or down and commented on and the database can grow organically.


Howto is good.

--
Marie

_______________________________________________
fenics mailing list
[email protected]
http://fenicsproject.org/mailman/listinfo/fenics

Reply via email to