[kepler-dev] Synchronizing Ptolemy II and Kepler

Christopher Hylands Brooks cxh at eecs.berkeley.edu
Thu Nov 13 10:38:19 PST 2003

With regard to synchronizing Ptolemy II and Kepler, there are several

1. Yearly updates:

The classic - we release Ptolemy II once a year and Kepler
merges our changes in to their code base.

CVS has the notion of vendors, where one can merge in changes
from a vendor, see

I've tried using CVS vendors it can be a little tricky.

The disadvantage to this is that the coupling is very loose
between Ptolemy II and other projects and bug fixes take
a long time show up.

I don't recommend this choice.

2. User based updates:

[Mescal is a project here at UCB that also uses Ptolemy II]

Currently, Mescal users also have read/write access to 
the Ptolemy tree, but they do not update their ptII tree that
often.  This is a good thing because portions of Ptolemy II 
are under active development and sometimes it takes a few
iterations over a few days to resolve design issues.

Having Mescal users ride the whipsaw of the Ptolemy II development
process is not good for Mescal developer morale.

However, by delaying the merge, they integration becomes a larger and
larger issue.

One issue that comes up is that Mescal users will find
bugs that we fix in the devel repository, but to get
the bug fix Mescal users need to develop update their
entire Ptolemy II tree.

This choice works reasonably well for a small number of developers,
but breaks down as more and more developers are trying
to set up their trees and end up downloading the active
Ptolemy II development tree at a time when we are resolving

We could start with user driven updates, where a few kepler
developers had read only access to the Ptolemy II tree to get

3. Snapshot releases:
Here, we create snapshots as needed and users update their
codebase, possibly as a vendor merge, or else by
doing a cvs update, or else by downloading a tar file. 

Ideally, this would happen on a regular basis.

However, I don't currently have the time to do this on a regular
basis, so doing it monthly is just not going to happen.  However, it
can happen on an as needed basis.

It usually takes time over a few days to create a snapshot
where Ptolemy developers are not checking in large wholesale
changes and I iron out configuration and build problems.

Usually groups like Mescal or Kepler will want to get a Ptolemy
snapshot right before they do a code freeze of their code, or
when there is a significant bug fix that really requires a wholesale

I think periodic snapshots are better than monthly snapshots.

Eventually, we should move towards snapshot releases that are
available for download


More information about the Kepler-dev mailing list