dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Tue, Oct 25, 2011 at 05:29:15PM +0100, Garth N. Wells wrote:
> 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.

That's a good point, but how do we differentiate between a branch and
a series?

If I understand correctly, you suggest having

* two branches: trunk + latest stable (and old stable that we can ignore)
* many series to which we can target stuff

My only hangup is that the Launchpad visualization does not
differentiate between series and branches, or perhaps more precisely,
series to which branches have been connected and those that are only
used for planning.

--
Anders