[dune-pdelab] PDELab release

[Steffen Müthing]

Hi Christian,

> Am 05.05.2015 um 17:13 schrieb Christian Engwer <christian.engwer at uni-muenster.de>:
> 
> 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.

judging from the general feedback, that seems settled, then.

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

Ditto.

> 
>> 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)

I fully agree, but that is probably too much work before 2.4. OTOH, we should at least
make sure we don’t spew heaps of warnings at our users (and I also think that it is important
to have reasonably clean code in the local operators - they serve as templates for most user
code, and we should try and present a somewhat clear coding style in there…).

> * we should update the finiteelementmaps to recent changes in
>  localfunctions

Oh, I think I missed something there. What changed 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.

Again, that’s something else that requires a little more work. We’ll have to discuss here in Heidelberg
whether there is time to do a mini PDELab sprint and tackle some of those before 2.4.

> 
> 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.

In keeping with the last two paragraphs, I cloned PDELab and the Howto into our local GitLab instance
in Heidelberg at http://conan2.iwr.uni-heidelberg.de/git/groups/pdelab

If you want to help with the process and do not yet have an account, please send me an email and I’ll invite you.

So my idea of the whole process is as follows: If you have a bug or a feature that you want in for 2.4, open a bug, and
we will use that as a thread to discuss the issue. As soon as we have figured out whether / how we want to tackle it,
someone starts to code. All coding happens in a feature branch (even if it’s only a small bugfix!). Once you’re done,
you push the feature branch to GitLab and open a merge request. Optimally, you mention the bug in the merge request
(e.g.: The bug is #42, so you write in your merge request: „This fixes #42“ or something similar). That way, GitLab connects
the bug and the merge request. Then we can use the merge request to discuss any problems with that implementation,
and the person working on it can keep pushing to the same branch (GitLab will automatically update the merge request).
Finally, the branch gets merged using „git merge —no-ff“, which automatically closes the merge request (and, if you have
written „fixes #42“, also closes the bug).

All code branches should start from master and should *never* be rebased, otherwise GitLab runs into problems.

Sound good?

Steffen

PS: I haven’t yet setup GitLab to automatically push updates to git.dune-project.org, I’ll do that tomorrow.

> 
> Ciao
> Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dune-project.org/pipermail/dune-pdelab/attachments/20150506/a0effe1a/attachment.sig>