fenics team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Mon, Feb 25, 2013 at 10:13:44AM +0100, Martin Sandve Alnæs wrote:
> Some thoughts I have now on the different aspects:
> - A workflow that mixes two revision control systems is not sustainable.
> It's bound to cause more problems than it solves. In particular considering
> that most fenics developers prefer not having to learn the details of a
> single system.

Agree.

> - Releases are not a big problem either way. Releasing more often will
> reduce the per-release cost of blueprint and bug management, and allow
> Johannes to keep the release process automated with lp scripting. If we
> want one release for users, we can have that without repository change by
> just checking out all current projects into a fenics/ directory and making
> a tarball of that.

Depends on whether Johannes can script everything. It's a big relief
for the rest of us if Johannes makes the releases, but if it takes him
a full day, then that's still many wasted hours.

> - If a good workflow with the unified repository requires not mixing
> changes across components in one commit, I don't see any gain at all,
> that's how it always is today. What we can not do without a unified
> repository is commits that span multiple projects, for interface changes
> that do affect multiple projects. If that's inconvenient to do, a unified
> repository is worthless from my point of view.

Agree, we should definitely be able to commit for multiple components
at once. Otherwise there's no point.

> - I think the two-way split (keeping dolfin separate, joining at least
> ufc-ffc-ufl) sounds most compelling and carries less risk.

I'm still tempted by having one big repo.

> - The way I see it now, the main backside of the unification (assuming a
> two-way split) is the complexity of backporting bug fixes. Worst case
> scenario there is having to do manual patching, but it may be easier and we
> don't do that much backporting.

Why is that more difficult with one repository? You mean to versions
that existed before the unification? In that case, it's a problem that
will go away as soon as we stop supporting those old versions...

-- 
Anders


>>
>> I'm not sure that's what we need. The point of the proposed change is
>> to make it easy for developers to work on 'fenics' without having to
>> worry about syncing and merging with multiple sources.
>>
>>
>> I wouldn't mind changing from bzr to git but the point of a change
>> would have to be to make things simpler, not more complex.
>>
>>
>> Thanks for the demo.
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~fenics
>> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fenics
>> More help   : https://help.launchpad.net/ListHelp
>>