On Tuesday October 25 2011 09:29:15 Garth N. Wells wrote: > On 25 October 2011 17:25, Anders Logg <l...@simula.no> wrote: > > On Tue, Oct 25, 2011 at 09:21:49AM -0700, Johan Hake wrote: > >> On Tuesday October 25 2011 09:11:49 Anders Logg wrote: > >> > On Tue, Oct 25, 2011 at 09:00:53AM -0700, Johan Hake wrote: > >> > > On Tuesday October 25 2011 06:36:11 Anders Logg wrote: > >> > > > On Tue, Oct 25, 2011 at 01:59:13PM +0100, Garth N. Wells wrote: > >> > > > > On 25 October 2011 13:10, Anders Logg <l...@simula.no> wrote: > >> > > > > > On Tue, Oct 25, 2011 at 10:01:45AM +0200, Martin Alnæs wrote: > >> > > > > >> Martin > >> > > > > >> > >> > > > > >> Den 25. okt. 2011 kl. 08:11 skrev Anders Logg <l...@simula.no>: > >> > > > > >> > On Mon, Oct 24, 2011 at 03:45:26PM -0700, Johan Hake wrote: > >> > > > > >> >> On Monday October 24 2011 15:37:08 Garth N. Wells wrote: > >> > > > > >> >>> On 24 October 2011 23:29, Johan Hake > >> > > > > >> >>> <johan.h...@gmail.com> > >> > >> wrote: > >> > > > > >> >>>> On Monday October 24 2011 14:53:41 Garth N. Wells wrote: > >> > > > > >> >>>>> On 24 October 2011 22:11, Anders Logg <l...@simula.no> wrote: > >> > > > > >> >>>>>> On Mon, Oct 24, 2011 at 10:14:43AM -0700, Johan Hake wrote: > >> > > > > >> >>>>>>> On Monday October 24 2011 09:45:40 Garth N. Wells wrote: > >> > > > > >> >>>>>>>> On 24 October 2011 17:35, Garth N. Wells > >> > > > > >> >>>>>>>> <gn...@cam.ac.uk> > >> > > > >> > > wrote: > >> > > > > >> >>>>>>>>> On 24 October 2011 17:31, Garth N. Wells > >> > > > > >> >>>>>>>>> <gn...@cam.ac.uk> > >> > > > >> > > wrote: > >> > > > > >> >>>>>>>>>> On 24 October 2011 16:58, Anders Logg > >> > > > > >> >>>>>>>>>> <l...@simula.no> > >> > > > >> > > wrote: > >> > > > > >> >>>>>>>>>>> You mean follow Marie's suggestion but wait until > >> > > > > >> >>>>>>>>>>> we have released 1.0-beta2? > >> > > > > >> >>>>>>>>>> > >> > > > > >> >>>>>>>>>> I don't really see the need to wait. > >> > > > > >> >>>>>>>>>> > >> > > > > >> >>>>>>>>>> I've registered a new series. The code is at > >> > > > > >> >>>>>>>>>> > >> > > > > >> >>>>>>>>>> https://code.launchpad.net/~dolfin-core/dolfin/dol > >> > > > > >> >>>>>>>>>> fin-1 .1 > >> > > > > >> >>>>>>>>>> > >> > > > > >> >>>>>>>>>> We can play around with how best to configure > >> > > > > >> >>>>>>>>>> things. I had a look at a couple of projects on > >> > > > > >> >>>>>>>>>> Launchpad to see how they do it. > >> > > > > >> >>>>>>>>> > >> > > > > >> >>>>>>>>> Here are some examples: > >> > > > > >> >>>>>>>>> https://launchpad.net/unity > >> > > > > >> >>>>>>>>> https://launchpad.net/inkscape > >> > > > > >> >>>>>>>>> > >> > > > > >> >>>>>>>>> I think that we should keep trunk for development, > >> > > > > >> >>>>>>>>> and each time we get ready for a release series > >> > > > > >> >>>>>>>>> (1.0, 2.0, etc) create a new series for it. > >> > > > > >> >>>>>>>> > >> > > > > >> >>>>>>>> I made tried a few small changes on Launchpad - take > >> > > > > >> >>>>>>>> a look at the overview page. > >> > > > > >> >>>>>>>> > >> > > > > >> >>>>>>>> Note that the '1.0' branch is now > >> > > > > >> >>>>>>>> > >> > > > > >> >>>>>>>> lp:dolfin/1.0 > >> > > > > >> >>>>>>>> > >> > > > > >> >>>>>>>> lp:dolfin points automatically to the branch which > >> > > > > >> >>>>>>>> is associated with the development series (which is > >> > > > > >> >>>>>>>> now 1.1). > >> > > > > >> >>>>>>> > >> > > > > >> >>>>>>> Looks good! > >> > > > > >> >>>>>>> > >> > > > > >> >>>>>>> Not sure we should call the development branch 1.1 > >> > > > > >> >>>>>>> though. If we are going to keep series for releases > >> > > > > >> >>>>>>> I think we can branch of a 1.1 series once the > >> > > > > >> >>>>>>> release is in preparation. This series will then be > >> > > > > >> >>>>>>> for backporting of bug fixes. > >> > > > > >> >>>>>> > >> > > > > >> >>>>>> Agree, the development branch should be called trunk. > >> > > > > >> >>>>>> Then we branch off 1.1 when we get near release. > >> > > > > >> >>>>> > >> > > > > >> >>>>> Take a look now. > >> > > > > >> >>>> > >> > > > > >> >>>> Now it looks like there is one trunk and one 1.1 series. > >> > > > > >> >>>> Is that correct? > >> > > > > >> >>> > >> > > > > >> >>> Yes. There is no 1.1 branch, but there is a 1.1 series > >> > > > > >> >>> and a milestone so that we can target bugs and > >> > > > > >> >>> blueprints. We could also add a 1.2 series. > >> > > > > >> >>> > >> > > > > >> >>> Once most targeted 1.1 bugs and blueprints are closed, we > >> > > > > >> >>> can create a branch from trunk to prepare for release. > >> > > > > >> >> > >> > > > > >> >> Ok, slowly getting there! > >> > > > > >> > > >> > > > > >> > I still don't understand this model. Where should > >> > > > > >> > development happen? I expect it to happen in trunk, but > >> > > > > >> > then it won't go into 1.1. > >> > > > > >> > > >> > > > > >> > It now looks like we have to worry about three series: the > >> > > > > >> > stable 1.0 branch, the 1.1 branch and trunk. I prefer a > >> > > > > >> > simpler model with just two branches: stable and > >> > > > > >> > development and then "branching" off the development > >> > > > > >> > branch when we feel stable. > >> > > > > >> > >> > > > > >> Series != branch. > >> > > > > >> > >> > > > > >> There is no 1.1 branch yet, only the 1.1 series for targeting > >> > > > > >> stuff. There are currently two branches, trunk and 1.0.x. > >> > > > > >> Development always happens against trunk. > >> > > > > > > >> > > > > > That sounds good, but then I find the Launchpad graphics > >> > > > > > confusing: > >> > > > > > > >> > > > > > https://launchpad.net/dolfin/+series > >> > > > > > > >> > > > > > It still looks like three branches/series to me. > >> > > > > > > >> > > > > >> When entering testing phase before a release, trunk will be > >> > > > > >> branched into 1.1.x just as it was now branched into 1.0.x. > >> > > > > >> Bug fixes for 1.0.x will be pushed into the 1.0.x branch as > >> > > > > >> well as trunk. > >> > > > > >> > >> > > > > >> I like the model. I do not see how this works out with the > >> > > > > >> other projects yet. > >> > > > > > > >> > > > > > Does this mean that next time we feel like we've added a new > >> > > > > > important feature that we want to release, that should be > >> > > > > > released as 1.1.0? And then we need to go through the whole > >> > > > > > cycle of beta releases and release candidates? > >> > > > > > > >> > > > > > I think we need a model where we can make "development > >> > > > > > releases" that add new features without the big overhead of > >> > > > > > several months of testing and stabilization. But once in a > >> > > > > > while (say once every year), we make a new "stable" release > >> > > > > > that we maintain for a while. > >> > > > > > >> > > > > That sounds a bit like the odd (testing)/even (stable) release > >> > > > > numbering. > >> > > > > >> > > > Yes, that's one way to solve it. The point is that I think we > >> > > > should be able to make releases from the development branch > >> > > > without needing to start a new stable branch every time we add a > >> > > > new feature. > >> > > > > >> > > > > We could create milestones 1.1-pre0, 1.1-pre1, etc. > >> > > > > >> > > > Yes, that could work too. > >> > > > > >> > > > So instead of > >> > > > > >> > > > 1.1.0, 1.1.1, 1.1.2, ... development releases > >> > > > 1.2.0-beta1, 1.2.0-beta2, ... beta releases (approaching > >> > > > stable) 1.2.0-rc1, 1.2.0-rc2, ... release candidates > >> > > > (only bug fixes) 1.2.0, 1.2.1, ... stable > >> > > > releases with bug fixes > >> > > > > >> > > > we do > >> > > > > >> > > > 1.1-pre0, 1.1-pre1, 1.1-pre2, ... development releases > >> > > > 1.1.0-beta1, 1.1.0-beta2, ... beta releases (approaching > >> > > > stable) 1.1.0-rc1, 1.1.0-rc2, ... release candidates > >> > > > (only bug fixes) 1.1.0, 1.1.1, ... stable > >> > > > releases with bug fixes > >> > > > > >> > > > ? > >> > > > > >> > > > Then it's only a naming issue. Either one is fine with me. > >> > > > >> > > I am fine with either one too. > >> > > > >> > > That said I have the feeling that the release of 1.0 was a happening > >> > > that was fuelled by the release of the book. When we do not have a > >> > > book that burn our backs I have a feeling we are going to fallback > >> > > into the "old" habbit of continuous developing with minor releases. > >> > > > >> > > If we are going to adopt a stable/unstable release we need a system > >> > > of deadlines, which forces us to go in some sort of stabalizing > >> > > mode. Most _big_ software projects have that, but I am not fully > >> > > convinced we need it or are able to enforce such a scheme on FEniCS > >> > > development. > >> > > >> > I think we'll find out. Whenever we feel like we have enough new > >> > features for a new stable branch, we go into beta/rc mode for a little > >> > while and then bump Y. I think the second naming scheme avove might > >> > work fine. Let's try it. > >> > > >> > But can someone explain the picture of the series/branches on the > >> > DOLFIN Launchpad page? I find it confusing. It surely looks like three > >> > "branches" to me. > >> > >> It helps thinking > >> > >> series != branch > > > > I realize that, but they both seem to be visualized the same way. > > > >> But I think we can do without the 1.1 series for now. That one we > >> establish once we go into release mode, and considering your answer > >> above, this wont happen too often. > > I think that we do need it. Is part of planing and setting goals.
Ok, that makes sense. > >> I suggest we add the devlopment milestones to the trunk series instead > >> of having a dedicated series for these. This means we add: > >> > >> 1.1-pre0 (or 1.1 depending on naming scheme) > >> > >> to trunk. > > > > Sounds good to me. > > It will get out of control - we'll end up with 10's of milestones in > the trunk series. Having 1.1, 1.2, 2.0, etc gives structure to goal > setting. Sure but then that would only be for the stable releases. We need some sort of milestones for the development (pre) releases too. It is these I suggest we keep in trunk. We can still have a stable release series with milstones gathering larger blueprints and bugs. Johan > Garth > > > -- > > Anders > > > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~dolfin > > Post to : dolfin@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~dolfin > > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
