fenics team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 20 February 2013 23:35, Anders Logg <logg@xxxxxxxxx> wrote:
> On Wed, Feb 20, 2013 at 10:15:20PM +0000, Garth N. Wells wrote:
>>> It seems to me there are essentially three groups that this suggestion
>>> will affect in different ways:
>>>
>>> 1. Core developers who have to suffer the hassle of making multiple
>>> releases and working every day in multiple repositories.
>>>
>>> 2. Advanced users who want to pick and choose specific components.
>>>
>>> 3. Users who don't really care how the code is organized as long as it
>>> can be installed easily.
>>>
>>> I think the suggestion will be a big relief for the group (1) of core
>>> developers (5-10 people) and it will have a positive effect on the big
>>> group of users (> 1000 people?) who don't need to worry about matching
>>> version numbers. But it might be a small setback for the relatively
>>> small group (2) of advanced users.
>>>
>> I'm still not fully convinced either way. I find the concept of nested
>> repositories appealing. How convenient it is in practice I don't know.
>> Would someone who has spoken in favour of nested repositories be
>> wiling to make an example somewhere that we could test? I'm open to
>> changing version control system if something else suits our needs.
>
> Same here, but we're fairly committed to Launchpad and Launchpad does
> not do git.
>

Hopefully there is a volunteer to show us how it would work with
nested repos. It would have to be pretty compelling to contemplate
moving from bzr (Launchpad supports automated import from other
version control systems).

I'd also like to see how bzr handles a very large unified repository.
Recently the speed of bzr on larger repositories has been bugging me.

> And will a nested repository solve the problem of making multiple
> releases?
>

We can choose to make just one release.

Garth

> --
> Anders
>
>
>>> I might be wrong but I estimate the size of group (2) as somewhere
>>> around 5-10 people and I think we've heard from all of them in this
>>> discussion. :-) So my suggestion would be to go ahead with the
>>> proposal and while doing so make sure to structure the new repo and
>>> build system in such a way that it's easy to install single
>>> components.
>>>
>>> The extra hassle for users that only want UFL would then be to
>>> download a bigger tarball, fenics-2.0.0.tar.gz instead of
>>> ufl-2.0.0.tar.gz. But apart from that, it would just be something like
>>>
>>> $ cmake -DFENICS_ENABLE_ONLY_UFL . # or similar...
>>> $ make install
>>>
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~fenics
>>> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~fenics
>>> More help   : https://help.launchpad.net/ListHelp