fenics team mailing list archive

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

On 26 February 2013 01:16, Anders Logg <logg@xxxxxxxxx> wrote:
> 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.
>

I expect the more frequent releases will reduce the burden because
less script updating will be required. The longer it's left, the more
that changes.

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

Agree (with some painful recent debugging in mind around changesets
where changes were made in different repositories).

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

Even more granular would be ufc-ffc. That way, FFC would contain all
the code formatting.

> I'm still tempted by having one big repo.
>

I'm inclined to stay close to the status quo. If a big repo is
contemplated, someone should make one and we can test if it's workable
with bzr. It may just be too big and bzr too slow.

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

I'd advocate more

    frequent releases = less need for backporting

Garth

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