dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

Johan Jansson wrote:
> On Thu, Oct 26, 2006 at 01:29:02PM +0200, Anders Logg wrote:
>> I'm not so sure I like the branched development we have now with a
>> separate dolfin-kth. The consequence of this development is that the
>> core development takes place in the main dolfin tree (mostly by Garth
>> and myself), while you work on your own things in dolfin-kth.
>>
>> If you instead worked in the main dolfin tree, you would be forced to
>> keep up with and contribute to the development of the core
>> functionality which I would like better.
>>
>> I think separate trees should be something that we create temporarily
>> for testing and implementing new features before merging back into the
>> main tree. It should not be something permanent since it would then in
>> practice be a fork.
>>
>> /Anders
> 
> The main reason for having a separate, stable branch is to enable
> non-core DOLFIN developers to participate in module development. We
> have some students here at KTH using DOLFIN for example, and they are
> probably not able (or willing) to be forced to contribute to core
> development. The result of simultaneous core and module development
> for them is time wasted and perhaps eventually project failure because
> they never get started with their main work
> 
> How are you managing this with your students in Delft Garth?
>

They work against the latest release. That is the stable version :).

If they need new functionality from the kernel (which is not often),
they move to the development version. We haven't done it often yet, but
when something is ready to do into the development version, they pass it
on to me and I commit it. We have a generic plasticity solver which we
hope to add very soon (users can provide their own yield function,
plastic potential, hardening function, etc to overide the default choice
of J2).

> But sure, perhaps the branching does not need to be permanent. We
> could define the main branch as stable, and then when we make changes
> which might break core functionality, we make a temporary unstable
> branch.
> 

Let's make temporary branches when making changes which are expected to
cause major problems for an extended period (say for more than a few
hours). Sounds simple.

> I think we're doing ok on balancing core development and other
> duties. If you try to do everything at once and overextend yourself,
> then you usually lose perspective and creativity in my
> experience. Perhaps some more time should be spent on maintenance, but
> as I said, I think we're doing pretty ok.

What I would like is to create a "release candidate" branch just before
a new release to give a few days to runs tests with all the different
options, different platforms and different compilers.

> 
> For the longer term, we should plan how to engage more core developers
> (as well as module developers). There's much interest in FEniCS, so we
> should be able to achieve that. I think we have some good ideas,
> perhaps we can discuss those kinds of topics at FENICS'06 as well.
> 

I'm all for distinguishing the modules. We could make them more like
"add-ons" which are built on the DOLFIN kernel.


Garth

>   Johan
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>