Subject: [Fenics] Development model

From: Anders Logg <[email-masked]>
Date: Fri, 28 Oct 2011 12:06:05 +0200

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

---

From: "Marie E. Rognes" <[email-masked]>
Date: Fri, 28 Oct 2011 14:09:45 +0200

> the proposal, have already said OK, but please respond anyway for the

Anders: thanks for summarizing and volunteering!

I think this looks good, and definitely something to try out. In 
particular, I think that the combination of lightweight (snapshot) and 
heavyweight (stable) releases could be a good way to span the range of 
priorities and focii within the development group.

--
Marie

---

From: Benjamin Kehlet <[email-masked]>
Date: Fri, 28 Oct 2011 14:12:09 +0200

2011/10/28 Marie E. Rognes <[email-masked]>:
> I think this looks good, and definitely something to try out. In particular,
> I think that the combination of lightweight (snapshot) and heavyweight
> (stable) releases could be a good way to span the range of priorities and
> focii within the development group.
>
> --
> Marie

Agree. Looks good.

Benjamin

>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : [email-masked]
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp
>

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Fri, 28 Oct 2011 14:43:04 +0200

> Benjamin

Looks good.

Martin

---

From: Kent-Andre Mardal <[email-masked]>
Date: Fri, 28 Oct 2011 14:50:02 +0200

> the proposal, have already said OK, but please respond anyway for the

I think this is a good development model!

Kent

---

From: Andre Massing <[email-masked]>
Date: Fri, 28 Oct 2011 15:01:44 +0200

On 10/28/2011 02:50 PM, Kent-Andre Mardal wrote:
>> 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:
>> 
>> 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.
>> 
> 
> 

Totally agree! That looks really like a good model, especially the
possibility and separation of spontaneously releasing snapshots on the
one hand and have a thoroughly prepared release with a predictable
time frame /schedule on the other.

Nice picture by the way. Who is the artist :)?

Andre

> 
> Kent
> 
> 
>> -- Anders
>> 
>> _______________________________________________ Mailing list:
>> https://launchpad.net/~fenics Post to     :
>> [email-masked] Unsubscribe :
>> https://launchpad.net/~fenics More help   :
>> https://help.launchpad.net/ListHelp
>> 
> 
> 
> 
> _______________________________________________ Mailing list:
> https://launchpad.net/~fenics Post to     :
> [email-masked] Unsubscribe :
> https://launchpad.net/~fenics More help   :
> https://help.launchpad.net/ListHelp

---

From: Anders Logg <[email-masked]>
Date: Fri, 28 Oct 2011 15:15:24 +0200

On Fri, Oct 28, 2011 at 03:01:44PM +0200, Andre Massing wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Thanks! :-)

--
Anders

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.17 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJOqqe4AAoJEA79ggnbq9dmv8MIANNd0YYteliuIZLzB8+uIZMS
> 3E1iYDq7+XhpGnDao6bH0eIi8GZ6ce6Z+CfQtLLJx6oxDFVHLuqwBZr1EZmYfQMG
> 1KjljMLJHgAvFO7rCD9UMZLZv7W63CDdNv30/zeSrh1Yrl4vCCZEV6ydUNVGWfxi
> bWKnoo7GAaGbRIctapR7jRybk02L5rsw6hbTZxGuLkjrHEG9nRM4N5EN3wO0s/fY
> mHj71QeknCgxovPvRGYa8vtenNr2AHCb4igbtjw7U22dls37fZgAgun+bofUiSBz
> kJ53XPT51sYsEIvKmpvv4H9Dy0dH3A1Uj7oGlEEUDwpZQunentJXo6qmzU1Hljg=
> =syl5
> -----END PGP SIGNATURE-----
>

---

From: Johan Hake <[email-masked]>
Date: Fri, 28 Oct 2011 08:35:32 -0700

So the simula people sits down and find a development model, and all the 
simula people agree it is a good one ;)

That said, I also think it is a good suggestion!

Johan

---

From: Johannes Ring <[email-masked]>
Date: Fri, 28 Oct 2011 18:43:46 +0200

> the proposal, have already said OK, but please respond anyway for the

I also agree that it looks like a good model, however, as a Debian
maintainer, I'm a bit worried about the version numbering. For some
time ago we agreed (at least some of us) that at least Y should be
bumped on interface changes in the DOLFIN shared library. Does this
still fit in with this model?

I also don't like version numbers like 1.1-pre1 because it isn't "less
than" for instance 1.1-beta1:

    $ dpkg --compare-versions 1.1-pre1 lt 1.1-beta1; echo $?
   1

Can we use something else than "pre"? How about "alpha"?

Johannes

---

From: "Garth N. Wells" <[email-masked]>
Date: Fri, 28 Oct 2011 18:06:20 +0100

> Can we use something else than "pre"? How about "alpha"?

Good point. Maybe we need to decide on which releases/snapshots we
package? Do we want to bother packing snapshots from trunk?

Garth

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Fri, 28 Oct 2011 19:09:14 +0200

When branching out for a full release with feature changes, y in x.y.z will
be bumped. When only bugfixes happen in that series later, z is bumped.

Pre is just lightweight snapshots, but having the option of packages for
collaborators is good, so if using alpha is better then I am all for that.

Martin

---

From: Martin Alnæs <[email-masked]>
Date: Fri, 28 Oct 2011 19:12:33 +0200

Packaging prereleases could be done on an as needed basis. The use case for this is quick distribution of new features to research partners who are less involved with fenics.

Martin

---

From: Anders Logg <[email-masked]>
Date: Fri, 28 Oct 2011 22:46:03 +0200

> simula people agree it is a good one ;)

Even worse, I had to order them all to say so! :-)

--
Anders

---

From: Johan Hake <[email-masked]>
Date: Fri, 28 Oct 2011 13:50:43 -0700

> Even worse, I had to order them all to say so! :-)

I bet so ;)

Johan

---

From: Anders Logg <[email-masked]>
Date: Fri, 28 Oct 2011 22:54:13 +0200

> > still fit in with this model?

Yes, I think so. In particular, all 1.0.z versions will be compatible
since z > 0 will only include bug fixes.

Then after 1.0.z something, the next *proper* version is 1.1.0, in
which new features can be introduced. I hope there won't be any
interface changes in 1.1.0 either (only added features and new
interfaces) so we don't break the book any time soon.

> Good point. Maybe we need to decide on which releases/snapshots we

Yes. alpha works fine too. I can update the image and the text.

> package? Do we want to bother packing snapshots from trunk?

I'm not sure. It seems that packages that go into Debian and Ubuntu
should be stable packages and by definition the snapshots are not
stable.

--
Anders

---

From: Kent-Andre Mardal <[email-masked]>
Date: Fri, 28 Oct 2011 23:15:56 +0200

> Even worse, I had to order them all to say so! :-)
You´re the boss ;-)

Kent

---

From: Andy Ray Terrel <[email-masked]>
Date: Sun, 30 Oct 2011 21:17:38 -0500

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.

1) Feature branches for work allows for multiple people to be working
on different parts of the code easily
2) Keep the hotfixes on a branches that are pulled into both the
mainline development and the stable release
3) Trims branches as soon as possible so you have a clear
understanding of where work is going.

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.

-- Andy

---

From: Johan Hake <[email-masked]>
Date: Sun, 30 Oct 2011 21:43:34 -0700

> http://nvie.com/posts/a-successful-git-branching-model/

That was a nice read!

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

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

> understanding of where work is going.

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

> 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

---

From: Johan Hake <[email-masked]>
Date: Sun, 30 Oct 2011 23:26:54 -0700

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:
> > 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.
> > 
> > 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.
> > 
> > We already have feature branches. They are mostly, as also suggested by
> > the link, excisting as private branches among the main developers.
> > 
> > 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.
> > 
> > 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.
> > 
> > larger features if you are not in the above physical places, Simula +
> > Garth lab?
> > 
> > Regards,
> > 
> > Johan
> > 
> >> -- Andy
> >>

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 31 Oct 2011 10:24:11 +0100

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

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

> claims directly on a list, but it is difficult to do anything about it if that

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

---

From: Martin Sandve Alnæs <[email-masked]>
Date: Mon, 31 Oct 2011 11:05:07 +0100

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

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

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

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

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

Martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 31 Oct 2011 11:05:08 +0100

> not see from the "inside".

Yes.

> hopefully stabilize now, and we will support 1.0 and fix its bugs for

Remember that one of the motivations for the many changes has been to
get all those changes in place before 1.0 so that we don't need to
change the interface after 1.0. I'm very happy with the current
interface and don't foresee any big changes in the near future. We
also have a quite extensive set of unit tests that check that *all*
code examples in the Tutorial and DOLFIN chapters in the book will
continue to run.

> problem, but otherwise I think:

My impression is that we have just the number of users that we want
and deserve at the moment. It would have been a problem to have 10x
more users. Now that 1.0 is (almost) here, I think we are ready for
more users (and developers).

> - We accept patches regularly, but do require that they are in a

I think the Launchpad system has good support for contributions. It's
easy to publish new branches and make merge requests and easy to
review and merge those branches.

> - With the fenics book we have tried hard to make the software well documented.

Yes.

--
Anders

---

From: Andy Ray Terrel <[email-masked]>
Date: Mon, 31 Oct 2011 14:44:30 -0500

Well that got a bit more response than I expected.  Anywho, I'll try
to answer things as I can but I just wanted to point out another model
that I know works well.  To be fair, I realize I'm a little rusty on
FEnCS software dev practices these days and unless my funding
situation radically changes, I don't see me making significant
contributions to the code base.  But I'm happy to show people how to
use it.

>> > claims directly on a list, but it is difficult to do anything about it if that

I've asked a few people to give me more feedback.  I think that there
is a tendency to flame on lists so people generally write off software
that doesn't work for them.  Personally, I like FEniCS because I can
hack my own things together with it but not everyone has written a
thesis with it =P.

> code examples in the Tutorial and DOLFIN chapters in the book will

So I would just say that we want different things.  For example,
rolling your own block solver in FEniCS isn't well streamlined.  Also,
if you want to use a feature in the C++ interface, there is little
recourse to do so in the Python interface.  I believe more in a very
open environment where users help inform such decisions.  Its harder
to keep the software stable, but the end product often suits users
much better.  There are very few software products that come out of
eight years of development without users that are usable by the
masses.  I've seen this with the FLAME group and I think FEniCS is
going to have to work really hard to get a large user base if that is
what it wants.

>> - Our response time on questions is low, but we do require that the

Yes, this is quite commendable.

>> - We accept patches regularly, but do require that they are in a

Yes, FEniCS is not Trilinos, but nonetheless other people in the
community have the impression that it is difficult to make a patch for
FEniCS.

> review and merge those branches.

I think it has some really nice features.

>> - With the fenics book we have tried hard to make the software well documented.

I think the book is great and regularly tell people to look at it.
But we are really focused on the Python layer and leave the C++ stuff
as an exercise to the reader to translate.

> Yes.

At this point, I'm fine with the usual smug "patches welcome" made
famous by SVN, but I'm just parroting things I've heard from the
community.  I'm sure there will be more conversation over some beers
in Lubbock.

-- Andy

---

From: Andy Ray Terrel <[email-masked]>
Date: Mon, 31 Oct 2011 14:51:52 -0500

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

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

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

> old releases as obsolete in launchpad at some point and stop fixing

Yes but won't they show up forever in bzr?

> 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

---

From: Martin Alnæs <[email-masked]>
Date: Mon, 31 Oct 2011 23:20:21 +0100

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

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

> example in SymPy, we can see what people are working on by just

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

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

> Yes but won't they show up forever in bzr?

Only on the launchpad server.

> Well it could be more my problem, but more I meant "the way FEniCS is

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

Martin

---

From: Johan Hake <[email-masked]>
Date: Mon, 31 Oct 2011 16:00:18 -0700

On Monday October 31 2011 15:20:21 Martin Alnæs wrote:
> 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.
> 

While this is true, you can use 

  bzr init-repository

to connect a set of branches to a shared repor, which typically is a 
development branch. This to share space for the different branches. But AFAIK 
the shared branches are not per se connected to the development branch (repo), 
they just share most of the revisions.

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

I have most of the other's branches locally on my computer, and can easily 
check out what they are doing.
 
Johan

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

---

From: Anders Logg <[email-masked]>
Date: Mon, 7 Nov 2011 21:41:14 +0100

> they just share most of the revisions.

Yes, I use this for sharing revisions between many branches, in
particular

  trunk
  trunk-logg
  1.0.x
  1.0.x-logg

--
Anders

---

From: Martin Alnæs <[email-masked]>
Date: Mon, 7 Nov 2011 23:24:12 +0100

> Yes, I use this for sharing revisions between many branches, in

That is just a local optimization, doesn't affect my point at all. It is probably hard to appreciate the difference without having worked with git though. The bottom line is I think Andy's git workflow looks great for git, and our new workflow looks good for us with bzr.

Martin

---

From: Anders Logg <[email-masked]>
Date: Mon, 7 Nov 2011 23:28:40 +0100

On Mon, Nov 07, 2011 at 11:24:12PM +0100, Martin Alnæs wrote:
> That is just a local optimization, doesn't affect my point at
> all. It is probably hard to appreciate the difference without having
> worked with git though. The bottom line is I think Andy's git
> workflow looks great for git, and our new workflow looks good for us
> with bzr.

I know. I just wanted to answer Johan's question which I interpreted as "Is
it safe to use a shared repo to store different branches like trunk
and 1.0.x?"

--
Anders

---

From: Johan Hake <[email-masked]>
Date: Mon, 7 Nov 2011 14:36:26 -0800

On Monday November 7 2011 14:28:40 Anders Logg wrote:
> > >>> 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.
> > >>> 
> > >> development branch. This to share space for the different branches.
> > >> But AFAIK the shared branches are not per se connected to the
> > >> development branch (repo), they just share most of the revisions.
> > > 

No question from my side! :) But thanks anyway!

Johan

> > >>>> On Mon, Oct 31, 2011 at 5:05 AM, Martin Sandve Alnæs
> > >>>> <[email-masked]>
> > >> 
> > >> wrote:
> > >>>>>> Here's the "model" that I've been using on several projects with
> > >>>>>> teams located across the globe.
> > >>>>>> 
> > >>>>>> There are a few differences here between the models and I don't
> > >>>>>> know how feasible they are with bazaar.
> > >>>>> 
> > >>>>> hotfixes towards any previous release later. I think that is
> > >>>>> valuable, and I don't see what having the master branch solves?
> > >>>> 
> > >>>> 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
> > >>>>> 
> > >>> 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'.
> > >> 
> > >> I have most of the other's branches locally on my computer, and can
> > >> easily check out what they are doing.
> > >> 
> > >> Johan
> > >> 
> > >>>> 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.
> > >>> 
> > >>>>> 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.
> > >>>> 
> > >>>>>> 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.
> > >>>>> 
> > >>>> Well it could be more my problem, but more I meant "the way FEniCS
> > >>>> is currently developed."
> > >>> 
> > >>>>>>> the following
> > >>>>>>> to serve as release manager this time. I'd be happy to step
> > >>>>>>> aside if someone else is motivated.
> > >>>>>>>