fenics team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

On 31 October 2011 07:26, Johan Hake <johan.hake@xxxxxxxxx> wrote:
> 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.

Me neither, but the feedback will be welcome, so please send us a summary :)

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

It would be interesting to know if their problems are basically the
same issues we know about and try to address, or something that we do
not see from the "inside".

I think we are in general agreement on the main cooperative challenges:
- The interface has been changing too much too often, this will
hopefully stabilize now, and we will support 1.0 and fix its bugs for
a while.
- With the new development plan we try to make the release process less chaotic.

As for wanting users, the rapid interface changes may have been a
problem, but otherwise I think:
- Our response time on questions is low, but we do require that the
questions make sense.
- We accept patches regularly, but do require that they are in a good state.
- With the fenics book we have tried hard to make the software well documented.

Martin


> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>