fenics team mailing list archive

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


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

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

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

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

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