fenics team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Sunday October 30 2011 19:17:38 Andy Ray Terrel 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/

That was a nice read!

> There are a few differences here between the models and I don't know
> how feasible they are with bazaar.

I do not see any problems using bzr with that model. 

I see a couple of differences between the proposed model and the one you 
present here:

  1) We do not have a master branch and hence not hotfix branches.
  
  2) We have snapshot releases which will not result in a separate branch 
     but just reflect a change in versioning numbers in the appropriate 
     files in the develop branch.

  3) AFAIK we have not considered doing all release related development,
     including bugfixes in a dedicated release branch. This means that 
     once we deside to go into release mode we make a branch. Fix bugs
     milestoned to that release. Change file numbering reflecting the 
     new release. And then after all this is done we merge the changes 
     back into the development branch

My comments:

I am not convinced we need a master branch. However, it looks like a clean 
development model...

I also think the snapshot releases (alpha) make sense for FEniCS, as we are a 
community driven project with little time dealing with large release related 
developments. 

I _do_ think we should consider the release related development approach 
desribed in your link Andy. It make sense and make it possible for features to 
be added to the development branch while a release get prepared.
 
> 1) Feature branches for work allows for multiple people to be working
> on different parts of the code easily

We already have feature branches. They are mostly, as also suggested by the 
link, excisting as private branches among the main developers. 

> 2) Keep the hotfixes on a branches that are pulled into both the
> mainline development and the stable release

We need to add a Master branch for it to make sense to have hotfix branches, I 
guess? Not convinced we need such a branch though.

> 3) Trims branches as soon as possible so you have a clear
> understanding of where work is going.

What do you mean with this? Merge with development as often as possible?

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

I think this is sad. It would be interesting to go into why this might be. We 
have had a couple of contributions lately. Is it something with the culture, 
rather than the development model? 

The last year or two we have had focus on demanding unit tests for new code. 
This raises the bars to contribute, but I think that is sane, and I guess this 
is not a main reason for difficulties to contribute? I also have the feeling 
that if someone have a ready patch with some feature implemented, it get 
reviewed, pretty fast with decent comment from developers. 

Maybe what you refere to is the difficulties to influence development of 
larger features if you are not in the above physical places, Simula + Garth 
lab?

Regards,

Johan

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