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