dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Oct 26, 2006 at 03:12:02PM +0200, Garth N. Wells wrote:
> 
> 
> Johan Jansson wrote:
> > On Thu, Oct 26, 2006 at 02:39:48PM +0200, Garth N. Wells wrote:
> >> Repositories are so easy to make, so just make some local ones to share
> >> developments against the stable version.
> > 
> > Ok, but then we're in agreement, since this is exactly what dolfin-kth
> > is. 
> 
> 
> >I think it's a good idea though to cc notifications to dolfin-dev,
> > because there might be changes in local repositories  which are not
> > only module-specific, 
> 
> Shouldn't these changes be made in DOLFIN?
> 
> and it's interesting for others to see what's
> > going on.
> >
> 
> I looked at the log for dolfin-kth, and couldn't see why most of the
> work (which is by Johan J.) isn't done directly in DOLFIN?
> 
> 
> >>> There's also the case
> >>> where a feature/fix might not yet exist in a release. One example is
> >>> that DOLFIN cannot use a locally installed Boost (if there also exists
> >>> an older system-installed version) with the latest release. This was a
> >>> requirement for using DOLFIN in the Linux environment at KTH
> >>> (CSC/NADA).
> >>>
> >> This doesn't happen very often, and when it does you can backport the
> >> change (the Boost problems is just a few lines in configure.ac), or you
> >> decide to move to the development version (and keep it fixed).
> >>
> >> Any approach that doesn't involve a fork will have some difficulties,
> >> but I don't think that they are that significant.
> >>
> >> Garth
> >>
> > 
> > Perhaps not, but it's still a lot better to be able to point people to
> > a specific version (or changeset) than to tell people to download an
> > old version and then make changes here and there.
> >
> 
> I agree. What about more frequent releases then? Would that help? If the
> latest release needs to be patched to get something working, let's make
> a release.

I think this is a good idea. We shouldn't wait too long between
releases, in particular since each release means that we need to
make sure everything works. It's only good if we need check that
things work more often. (And hopefully I can get some help with
creating releases.)

/Anders


> 
> Garth
> 
> 
> > Note that a branch is not a fork. Most major projects have several
> > branches.
> > 
> >   Johan
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/mailman/listinfo/dolfin-dev
> > 
> 
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/mailman/listinfo/dolfin-dev