fenics team mailing list archive

[Martin Alnæs <martinal@xxxxxxxxx>]

I'll just comment quickly on the bzr vs git workings for those who care.

Main point: in bzr you fetch one branch at a time (afaik*), while in git you often fetch a repo with multiple branches. This changes how branches are used.

*Please prove me wrong :)

Den 31. okt. 2011 kl. 20:51 skrev Andy Ray Terrel <andy.terrel@xxxxxxxxx>:

> On Mon, Oct 31, 2011 at 5:05 AM, Martin Sandve Alnæs <martinal@xxxxxxxxx> wrote:
>> On 31 October 2011 03:17, Andy Ray Terrel <andy.terrel@xxxxxxxxx> wrote:
>>> Here's the "model" that I've been using on several projects with teams
>>> located across the globe.
>>> 
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>> 
>>> There are a few differences here between the models and I don't know
>>> how feasible they are with bazaar.
>> 
>> I see 'master' here as an alias for 'the latest tag in the latest
>> release branch'. We want to keep the release branches to allow easy
>> hotfixes towards any previous release later. I think that is valuable,
>> and I don't see what having the master branch solves?
>> 
> 
> So this is a detail that is particular to git maybe.  Basically the
> master branch is a "clean" trace of the patches made to the code base.
> It gives a single line of how things are developed, rather than
> having to jump from branch to branch to see what happened.

Ok. In bzr, -no-ff is how merge always work, so if you always merge in the right direction you get the equivalent. If merges are sometimes done in the 'wrong' direction, I think master could play a similar role with bzr.


>>> 1) Feature branches for work allows for multiple people to be working
>>> on different parts of the code easily
>> 
>> We do something like this regularly, but I think we mostly use
>> personal branches with no feature name though. There could be
>> improvements to the way we use these branches.
>> 
> 
> So github does the publication of these branches really well.  For
> example in SymPy, we can see what people are working on by just
> fetching their repos.

In bzr, you never fetch a repo, you just get a single branch. This is the most important difference. But you can see on launchpad all personal dolfin branches there by going to the dolfin page and clicking 'code'.


>>> 2) Keep the hotfixes on a branches that are pulled into both the
>>> mainline development and the stable release
>> 
>> With the model Anders posted we would do hotfixes in the release
>> branch and make a 1.0.x bugfix release. This would be merged into
>> mainline (trunk). No need for a separate hotfix branch, since the
>> release branch should have only bugfixes for that release.
>> 
> 
> So it looks to me like a hotfix in Anders model, requires every active
> branch to have the patch applied.  Here you make a branch for the
> hotfix, review the fix, put it in the active dev and master (which is
> really a stable mainline), and finally delete the branch.  This model
> tries really hard to avoid the SVN style branches that live forever
> with only the dev and master being permanant.  Anders model looks to
> me that you will have a lot of branches in a small amount of time, but
> then again I could not be seeing that particular detail.

We will have a few new branches each year, but those just stay on launchpad and don't follow a repo around like in git. And branches that stay around for however long we want them to is a feature in our model, allowing easy hot fixes towards any previous release branch. We could delete them when obsolete, but there's no value in that since they just stay on the server.


>>> 3) Trims branches as soon as possible so you have a clear
>>> understanding of where work is going.
>> 
>> I think we understand where work is going with the new model: Features
>> go into trunk, and only bugfixes in release branches.
>> 
>> To reduce the cost of keeping release branches 'forever', we may mark
>> old releases as obsolete in launchpad at some point and stop fixing
>> bugs.
>> 
> 
> Yes but won't they show up forever in bzr?

Only on the launchpad server.


>>> Anywho, my thought has always been that FEniCS model makes it
>>> difficult for non-(Simula + Garth's lab) to contribute.  I've actually
>>> had people tell me this at conferences.  But then again I've also been
>>> told that FEniCS doesn't want users as well.
>> 
>> Not sure what the "FEniCS model" is here, but maybe that's part of the problem?
> 
> Well it could be more my problem, but more I meant "the way FEniCS is
> currently developed."

We weren't all happy ourselves, so hopefully the new model is a big step in the right direction.

Martin


> -- Andy
> 
>> 
>> Martin
>> 
>> 
>>> -- Andy
>>> 
>>> 
>>> On Fri, Oct 28, 2011 at 5:06 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>>>> Dear all,
>>>> 
>>>> There has been some concern regarding the lack of predictability in
>>>> FEniCS releases. Yesterday, some of us at Simula met to discuss what
>>>> can be done to improve the situation. The result is the following
>>>> draft for a future development model:
>>>> 
>>>>  http://fenicsproject.org/contributing/development_model.html
>>>> 
>>>> Please comment on the draft and suggest corrections.
>>>> 
>>>> The new development model calls for a "release manager" to coordinate
>>>> each stable release (currently 1.0). I can volunteer to serve as
>>>> release manager this time. I'd be happy to step aside if someone else
>>>> is motivated.
>>>> 
>>>> I know some of you, in particular those from Simula who helped draft
>>>> the proposal, have already said OK, but please respond anyway for the
>>>> record.
>>>> 
>>>> --
>>>> Anders
>>>> 
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~fenics
>>>> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~fenics
>>>> More help   : https://help.launchpad.net/ListHelp
>>>> 
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~fenics
>>> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~fenics
>>> More help   : https://help.launchpad.net/ListHelp
>>> 
>>