[dune-pdelab] PDELab release

[Christian Engwer]

Hi Steffen,

> 1) What will be our minimum compiler requirements? I am *very much* opposed to anything
>     below 4.6, as that gives us range-based for, clear semantics for move operations (I’ve had some
>     nasty problems with autogenerated move member functions in 4.5) as well as constexpr.
> 
>     That said, my suggestion would be GCC 4.7, as that also gives us template aliases and delegated
>     constructors. Moreover, I am unable to run decent testing for GCC < 4.7 on my machine because
>     DUNE itself doesn’t support older GCC on OS X, so until we have some automatic testing infrastructure
>     and a development model that makes it easy to use such an infrastructure (e.g. pull requests), I’ll probably
>     break GCC 4.6 from time to time.

4.7 is OK for me.

> 2) What’s our position regarding ALUGrid? My suggestion is to simply require the new dune-alugrid
>      module and be done with it.

#1

> 3) Somehow related to this: Christian already did some work on cleaning up the heaps of deprecation
>     warnings due to the changed grid interface, but IMHO we should do a coordinated sweep of the
>     complete code base PDELab and the Howto and also take the chance to improve coding style in
>     general: range-based for loops (e.g. for quadrature loops), store inside and outside entities and
>     geometries in variables for better performance etc.

I don't want to argue against a cleanup, but for pdelab itself, I
think it doesn't matter too much, there are more pressing problems...

* we should cleanup the local operators:
  - consistent parameters classes
  - unify nearly identical operators
  - fix or remove broken operators (e.g. MFD)
* we should update the finiteelementmaps to recent changes in
  localfunctions
* cleanup memory management (shared_ptr vs. copy vs. reference) in the
  pdelab guts
  ... ideally I should not have to keep pointers to heap-allocated
  objects in order to keep other objects valid, e.g. keep the GFS to
  have a valid discrete function.

then we have a few other things that become nicer with the recent changes

besides this the coding style in the howto is much more critical, as
it is the stuff, users will copy into their code and bad styles there
will give us hard times in the support. On the other hand updating the
howto is really a lot of work.

The last thing I would like to add is that time is limited and I would
rather not delay the pdelab release too much ;-) We should make a list
of topics and sort them according to priority.

An other thing... if we develop fixes in branches, we can easily merge
them to the master and the release-branche. Steffen and I discussed
already to try a no-push-to-master policy in pdelab to check the
implications on the workflow, before discussing such a thing for the
core modules. Perhaps this is the right time to start with such a policy.

Ciao
Christian