Subject: [Unicorn-dev] Plans for release

From: Johan Jansson <[email-masked]>
Date: Tue, 15 Jan 2008 16:50:47 +0100

Hi!

Unicorn has now been updated against the DOLFIN 0.7.1 interface and I'm 
planning to start updating for release. The plan is to have a 
synchronized release of FFC/DOLFIN/Unicorn to guarantee compatibility of 
the releases. Are there any objections for a release of DOLFIN and FFC 
in the next couple of days? I expect only minor issues to resolve during 
the synchronization, but there might be recent developments I've missed, 
so any comments are welcome.

The Unicorn repository is here:

http://www.fenics.org/hg/unicorn

The project page is here:

http://www.fenics.org/wiki/Unicorn

and a mailing list has been created as [email-masked]

  Johan

---

From: Kristian Oelgaard <[email-masked]>
Date: Tue, 15 Jan 2008 17:55:57 +0100

Quoting Anders Logg <[email-masked]>:

> On Tue, Jan 15, 2008 at 04:50:47PM +0100, Johan Jansson wrote:
> > Hi!
> > 
> There are quite a few things to fix in both FFC and DOLFIN before a
> release.
> 
> FFC:
> 
> 1. Use FooTransformedSpace in FIAT to get correct function spaces on
> UFC reference element. This also requires making a new release of
> FIAT.
> 
> 2. A few fixes are needed for the JIT compiler.
> 
> 3. Get BDM, RT, BDFM, Nedelec working when using FIAT transformed
> spaces.
> 
> 4. Maybe some fixes for quadrature elements. Kristian?

I'm working on some fixes, but I definitely expect to be finished before the end
of January.

Kristian
 
> DOLFIN:
> 
> 1. Computation of parallel dof map.
> 
> 2. Get parallel assembly working.
> 
> 3. Finish the implementation of linear algebra factories (still some
> problems with circular dependencies).
> 
> 4. Move to new scons-based build system.
> 
> I think a best-case scenario is we can have these fixed by the end of
> January, possibly 1-2 weeks later. Maybe the scons-based build system
> can wait if it takes time to finish.
> 
> -- 
> Anders
> _______________________________________________
> DOLFIN-dev mailing list
> [email-masked]
> http://www.fenics.org/mailman/listinfo/dolfin-dev
>

---

From: Johan Jansson <[email-masked]>
Date: Wed, 16 Jan 2008 11:14:41 +0100

Anders Logg wrote:
> On Tue, Jan 15, 2008 at 07:03:46PM +0100, Johan Hoffman wrote:
>   
>> It seems that the Unicorn release we are preparing for is not dependent on
>> any of the points above, so maybe we can do a special release right now
>> without these improvements? (It could be a DOLFIN 0.7.1-1 etc. or
>> similar?)
>>
>> Then there could be a more substantial next release (e.g. DOLFIN 0.7.2)
>> with the points listed fixed.
>>
>> /JH
>>     
>
> There are quite a few new features that have been added since 0.7.1 so
> 0.7.1-1 is not suitable (it's not a bugfix release). And before making
> a new release, it would be good to finish all the things that are only
> half-working.
>
> Maybe you can take a snapshot of the current hg if it works for you
> and put the tarball on the unicorn page, something like
> dolfin-unicorn-x.y.z.tar.gz?
>
>   
Ok, I understand. I think the best idea is to do both, i.e. first make a 
release of the current state of FFC/DOLFIN/Unicorn (with some naming 
scheme), and then in a few weeks make a point release with the standard 
quality assurance.

I think it would be a good idea to have quite frequent releases (even if 
they haven't been fully quality tested). How about introducing something 
like an "incremental" release naming scheme (or "milestone", or perhaps 
there are better name ideas). We could have releases named:

dolfin-incremental-<date>.tar.gz

and put them in an "incremental" directory.

This would implement the "release early, release often" principle that 
can sometimes drive productivity in open projects. Thus when someone 
wants a release of all or some FEniCS components, she can just do some 
limited testing, follow the standard release procedure, and make an 
incremental release.

To have a "dolfin-unicorn" release name implies that extra 
unicorn-specific changes have been made to DOLFIN, which is not the 
case. It's just supposed to be a release, but like we're discussing, 
with less quality assurance than a point release.

What do you think?

  Johan

---

From: Johan Jansson <[email-masked]>
Date: Wed, 16 Jan 2008 14:16:21 +0100

Anders Logg wrote:
>
> Release early and often is a good thing. There just hasn't been much
> pressure to get a release out for a while (probably since most
> users/developers use the hg version anyway).
>
>   
Do open projects which use DOLFIN make releases which rely on the hg 
version? Could someone from such a project comment on what they do? What 
does Simula do when they make a release of open software which relies on 
DOLFIN?
> Depending on what state the code is in when someone asks for a
> release, it may take from just a day to a couple of weeks to get a
> release ready. So if you just ask for a release earlier (like a couple
> of weeks before you need it), then it shouldn't be a problem.
>
> The dolfin-incremental thing looks like it complicates things. An
> alternative would be to make automatic daily snapshots so you can
> depend on dolfin-2008-01-16 for example.
>   
I don't think it's practical to depend on automatic snapshots, you would 
have to time your commands to some daily or hourly script, it seems a 
bit cumbersome. But sure, why not build on the snapshot system. When you 
want a persistent snapshot release, you run the snapshot script with a 
date tag. Or?
> On a related note, can we remove dolfin-stable and
> dolfin-testing? They haven't been updated for 6 months
I think we should have a working system in place before we remove old 
systems. But they can be removed if we have a usable alternative.

  Johan

---

From: Johan Jansson <[email-masked]>
Date: Wed, 16 Jan 2008 15:27:08 +0100

Anders Logg wrote:
> Simula has never made an open release of software depending on DOLFIN.
>
> Ola can probably say something more about this.
>
>   
Ok.
> You mean not making automatic snapshots but having a script that takes
> a snapshot with version number = YYYY-MM-DD?
>
> That could work. We just need to add a directory
>
>   http://www.fenics.org/pub/software/dolfin/snapshots
>
> and a simple script named makesnapshot (or similar) under scripts/ in
> DOLFIN that runs the script and uploads. We can run this script
> anytime at the request of anyone.
>   
Ok good, this would probably be enough to satisfy everyone.
> But is anyone using them? They don't seem to be maintained
No, they haven't been used lately. We've had a dolfin-kth repository 
which has filled the function of dolfin-testing for the "unicorn-kth" 
repository. But rather than extending such a setup to the FEniCS unicorn 
repository, I think it's a better idea to develop against frequent 
snapshot releases. So let's try that and remove dolfin-testing and 
dolfin-stable.

  Johan

---

From: Johan Jansson <[email-masked]>
Date: Wed, 16 Jan 2008 15:33:13 +0100

Ola Skavhaug wrote:
> Johan Jansson skrev den 16/01-2008 følgende:
>   
>> Anders Logg wrote:
>>     
> We don't. Our open software does not, to my knowledge, depend on DOLFIN.
> Instead we are merging our software _with_ DOLFIN. I.e., we are removing much
> of our code base (where DOLFIN has good alternatives), inheriting from DOLFIN
> where appropriate, and contributing to the DOLFIN development in order to
> influence it, such that we can solve our problems using DOLFIN(/PyCC). The
> release cycle problem is, however, from Simula's point of view, best solved by
> us contributing to the development of DOLFIN to speed up the releases
> (especially before releases).
>
> Ola
>   
Ok, that's good that you're merging software with DOLFIN.

What's your plan for higher-level software (like equation-specific 
solvers, PyCC) which depend on DOLFIN, will the solvers be open projects?

And are there any other open projects which use DOLFIN? Or is Unicorn 
the only one right now?

  Johan

---

From: Johan Jansson <[email-masked]>
Date: Wed, 16 Jan 2008 15:54:40 +0100

Ola Skavhaug wrote:
>> What's your plan for higher-level software (like equation-specific solvers, 
>> PyCC) which depend on DOLFIN, will the solvers be open projects?
>>     
>
> Yes, the PDE software from Simula will be open source.
>
> Ola
>
>   

Good!

  Johan
>> And are there any other open projects which use DOLFIN? Or is Unicorn the 
>> only one right now?
>>
>>  Johan
>>
>>