ffc team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Wed, Jan 16, 2008 at 11:14:41AM +0100, Johan Jansson wrote:
> Anders Logg wrote:
> > On Tue, Jan 15, 2008 at 07:03:46PM +0100, Johan Hoffman wrote:
> >   
> >>> On Tue, Jan 15, 2008 at 04:50:47PM +0100, Johan Jansson wrote:
> >>>       
> >>>> 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 unicorn-dev@xxxxxxxxxx
> >>>>
> >>>>   Johan
> >>>>         
> >>> 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?
> >>>
> >>> 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.
> >>>
> >>>       
> >> 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

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

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.

On a related note, can we remove dolfin-stable and
dolfin-testing? They haven't been updated for 6 months.

-- 
Anders