fenics team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Sunday October 30 2011 22:23:42 Ridgway Scott wrote:
> Maybe we should talk about Andy's comments at the FEniCS meeting
> this week in Lubbock.

That would be great. But unfortunately not all of us will be there, me 
included. 

I would also appreciate a bit more details about the nature and content of 
such claims. Obviously it is not very tempting to stand out and raise such 
claims directly on a list, but it is difficult to do anything about it if that 
is not done.

Johan
 
> Ridg
> 
> On Oct 30, 2011, at 9:43 PM, Johan Hake wrote:
> > 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
> > 
> > _______________________________________________
> > Mailing list: https://launchpad.net/~fenics
> > Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~fenics
> > More help   : https://help.launchpad.net/ListHelp