dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 25 October 2011 17:25, Anders Logg <logg@xxxxxxxxx> 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 <logg@xxxxxxxxx> 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 <logg@xxxxxxxxx>:
>> > > > > >> > 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.hake@xxxxxxxxx>
>> wrote:
>> > > > > >> >>>> On Monday October 24 2011 14:53:41 Garth N. Wells wrote:
>> > > > > >> >>>>> On 24 October 2011 22:11, Anders Logg <logg@xxxxxxxxx> 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
>> > > > > >> >>>>>>>> <gnw20@xxxxxxxxx>
>> > >
>> > > wrote:
>> > > > > >> >>>>>>>>> On 24 October 2011 17:31, Garth N. Wells
>> > > > > >> >>>>>>>>> <gnw20@xxxxxxxxx>
>> > >
>> > > wrote:
>> > > > > >> >>>>>>>>>> On 24 October 2011 16:58, Anders Logg <logg@xxxxxxxxx>
>> > >
>> > > 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/dolfin-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.

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

Garth


> --
> Anders
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp
>