For future development I agree that ufl+ufc+ffc make sense, but I think it is a good idea to keep Dolfin separate.
Best Johan > We definitely need to take some time to figure out such branching issues > before we are in too deep. One way to reduce the hit could be to merge ufl > and ufc into ffc. I dont know how well bzr will handle reverting and > merging files that are moved around. Also, the dolfin utils and ufc design > could get some overhaul for cleaner separation as Anders mentioned. > > Martin > Den 6. feb. 2013 18:42 skrev "David Ham" <[email protected]> > følgende: > >> I think Martin's suggestion of Dolfin + the rest as the split would >> largely meet my concerns, and it sounds like it mostly meets your >> concerns below as well. It also essentially takes the project back to >> being one almost Python only project with limited dependencies (except >> UFC but that's small) and Dolfin which is big and has more >> dependencies. It also preserves the solver-independent aspect of the >> first set of packages. >> >> I'm not going to attempt to tell you how to run your project so if you >> really need to go to one repository then we'll have to cope, but my >> preference would be the two way split above. >> >> Regards, >> >> David >> >> >> >> On 6 February 2013 17:28, Anders Logg <[email protected]> wrote: >> > On Wed, Feb 06, 2013 at 04:39:47PM +0000, David Ham wrote: >> >> Hi Martin, >> >> We're not amazingly happy about that idea. >> >> The design of FEniCS as I understand it provides a series of tools >> >> which *can* be used in conjunction but need not be. In particular, >> our >> >> toolchain (which currently revels in the name flop.py) employs UFL, >> >> FFC, FIAT and Instant, but not UFC or Dolfin (since we employ PyOP2 >> >> and Fluidity in those roles). Merging the repositories would give us >> a >> >> de facto Dolfin dependency which we don't need. It also more >> generally >> >> undermines the stand-alone nature of these tools and undermines the >> >> idea that these are generic tools which might usefully be used by >> >> solvers other than Dolfin (eg the UFL Dune project we heard about a >> >> while back). >> > >> > We could make installation targets for specific subpackages (those you >> > mention) and add tests run by the buildbot that those can actually be >> > installed and used (for a set of test problems of your choice) without >> > needing to build DOLFIN. >> > >> > The reason I suggested this in the first place was after sitting 5 >> > people for one whole day making the releases of DOLFIN, FFC, FIAT, >> > Instant, UFC, UFL. It sounds ridiculous but there is something like 20 >> > different steps to go through for each release (including pressing >> > buttons on Launchpad) so it's a big hassle for anyone wanting to make >> > a release. Then multiply that by a factor 6 and realize why we don't >> > make releases that often... >> > >> > Another issue is working on new features. The same factor of 6 (or >> > more commonly only just 3-4) applies there. >> > >> > We started out with 2 projects (DOLFIN + FIAT) which naturally were >> > separate (one C++ library and one Python library). Then we added FFC >> > and SyFi and UFL and UFC were added as a glue between the different >> > form compilers. At the time, this was an efficient way to collaborate >> > and allow different groups to work independently on interoperable >> > codes. The situation has since changed. Now most core developers touch >> > all the codes all the time so a common repository would be more >> > convenient. >> > >> > The reason for the proposed change is all about making life more >> > convenient for developers and cutting down on administrative overhead. >> > >> >> I am also concerned that having them all in the same repository would >> >> tempt people to break tool orthogonality by introducing >> >> cross-dependencies which are not necessary but might appear >> convenient >> >> to the coder at the time. This would potentially turn a de facto >> >> dependency into a real one and could really make our life hard. >> > >> > We will likely see code being moved from one place to the other, but >> > cross-dependencies could likely be avoided by introducing new tests. >> > One particular test would be to check that the UFL unit tests and the >> > FIAT unit tests run without installation of any of the other packages. >> > >> > -- >> > Anders >> > >> > >> > >> >>> Whether to merge all fenics projects into one repository was >> discussed >> >>> offline in january, my tests of today show that it is definitely >> feasible. >> >>> >> >>> Before we eventually do that, we should allow some time for people >> to >> >>> foresee eventual issues, e.g. we'll need changes to the buildbot, >> which >> >>> projects should be included, etc. >> >>> >> >>> The blueprint interface is not really a good place to discuss, as it >> doesn't >> >>> handle concurrent access by multiple users, so chip in on this >> thread >> if you >> >>> have anything to say. >> >>> >> >>> Here's a summary of pros and cons: >> >>> >> https://blueprints.launchpad.net/fenics/+spec/combine-projects-into-one-repository >> >>> including a link to an already merged repository prototype and a >> script to >> >>> create it. >> >>> >> >>> Martin >> >> >> >> -- >> Dr David Ham >> Department of Computing >> Imperial College London >> >> http://www.imperial.ac.uk/people/david.ham >> > _______________________________________________ > 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
