dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Wednesday October 5 2011 10:10:37 Anders Logg wrote:
> On Wed, Oct 05, 2011 at 09:47:42AM -0700, Johan Hake wrote:
> > On Wednesday October 5 2011 07:48:32 Garth N. Wells wrote:
> > > On 5 October 2011 13:01, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
> > > > A related topic is this: I think it would be a good idea to keep a
> > > > 1.0.x bugfix-only branch after the 1.0 release, and let all new
> > > > features go toward 1.1. This could be a general pattern for future
> > > > releases, or just for 1.0 and other particularly chosen future
> > > > releases. Otherwise a critical bug hard to find bug in 1.0 will
> > > > significantly reduce the value of the book. "Bugs" like "this doesn't
> > > > scale perfectly in parallell" would of course _not_ be fixed in 1.0.x
> > > > but be considered new features in 1.1++.
> > > 
> > > Having developers work in their own branches, at times quite
> > > extensively, has worked well which is why I suggested offline recently
> > > that we start a 1.1 branch now. This way developments are not held
> > > back, and we avoid new developments compromising 1.0.
> 
> It seems we all agree on this.
> 
> > I also agree with Martin's points, and I also think it would be nice to
> > have a stable branch for back porting bug fixes. We would then need a
> > buildbot for both the development branch and the stable branch.
> > 
> > I guess we also need to establish a policy for what bug fixes should be
> > backported? A simple rule would be to backport only critical bugs, which
> > does not change the syntax.
> > 
> > What is the preffered way of cherry picking revisions from the
> > development
> > 
> > version into a stable branch? Would it be:
> >   bzr merge -r 6003 ../trunk
> 
> I don't know.
> 
> Other issues to discuss:
> 
> 1. Is it possible in Launchpad to keep track of bugs that have been
> fixed in either the development version or the stable branch? Or must
> the bug be duplicated? Say we fix it in the development version but
> forget to fix it in the stable branch or vice versa?

If we introduce a stable branch as a series I think we can. But I still think 
each bug should be milestoned into the trunk series. We need to establish a 
stable series to be able to find out how it works with a single bug in 
severeal sereies.
 
> 2. Should the 1.0.x branch only be bug fixes so all new features end
> up in 1.1.x?

I think so. But then what is a bug and what is a feature ;) 

Johan

> --
> Anders
> 
> > Johan
> > 
> > > Garth
> > > 
> > > > Martin
> > > > 
> > > > On 5 October 2011 13:56, Marie E. Rognes <meg@xxxxxxxxx> wrote:
> > > >> I am (perhaps not too surprisingly) very much interested in getting
> > > >> DOLFIN/FEniCS 1.0 out the door.
> > > >> 
> > > >> I have signed up for some more bugs and can definitely fix those at
> > > >> a couple of days notice.
> > > >> 
> > > >> I strongly agree with Martin's fact-pinions on the importance of
> > > >> prioritizing and a well-tested 1.0.
> > > >> 
> > > >>> What's everyone's thoughts on the pending release of 1.0 and
> > > >>> addition of new features?
> > > >>> 
> > > >>> If we don't set a deadline or otherwise agree to get 1.0 out of the
> > > >>> door in the very near future, there's a chance that the list of
> > > >>> bugs and blueprints will continue to grow at a faster pace than we
> > > >>> can fix them.
> > > >>> 
> > > >>> For example, I've started sketching out a new class
> > > >>> UnassembledMatrix which might help to improve the speed of
> > > >>> assembly and possibly be used for a redesign of SystemAssembler. I
> > > >>> feel very tempted by it but at the same time realize it should
> > > >>> probably wait until 1.1.
> > > >>> 
> > > >>> My suggestion is as follows:
> > > >>> 
> > > >>> 1. Everyone take a look at blueprints/bugs targeted for 1.0-beta2:
> > > >>>   https://launchpad.net/dolfin/+milestone/1.0-beta2
> > > >>> 
> > > >>> Think about whether you can fix things today/tomorrow so we can
> > > >>> make a release of 1.0-beta2 this week. If not, move the items to
> > > >>> 1.0-rc1.
> > > >>> 
> > > >>> 2. Everyone take a look at blueprints/bugs targeted for 1.0-rc1:
> > > >>>   https://launchpad.net/dolfin/+milestone/1.0-rc1
> > > >>> 
> > > >>> Think about whether you can fix things within 2-3 weeks so we can
> > > >>> make a release of 1.0-rc1 by the end of the month. If not, discuss
> > > >>> the items in question on the mailing list and move to 1.1.
> > > >>> 
> > > >>> ?
> > > >> 
> > > >> _______________________________________________
> > > >> Mailing list: https://launchpad.net/~dolfin
> > > >> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > >> Unsubscribe : https://launchpad.net/~dolfin
> > > >> More help   : https://help.launchpad.net/ListHelp
> > > > 
> > > > _______________________________________________
> > > > Mailing list: https://launchpad.net/~dolfin
> > > > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > > Unsubscribe : https://launchpad.net/~dolfin
> > > > More help   : https://help.launchpad.net/ListHelp
> > > 
> > > _______________________________________________
> > > Mailing list: https://launchpad.net/~dolfin
> > > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > > Unsubscribe : https://launchpad.net/~dolfin
> > > More help   : https://help.launchpad.net/ListHelp
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~dolfin
> > Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~dolfin
> > More help   : https://help.launchpad.net/ListHelp