On Fri, Nov 28, 2014 at 11:23 AM, Marie E. Rognes <[email protected]> wrote: > 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?
That is fine by me. 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 _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
