[kepler-dev] Proposal: Kepler should work off a snapshot or release of Ptolemy instead of the trunk of Ptolemy

[Timothy McPhillips]

HI Matt,

I agree the main issue with building the kepler trunk against a  
snapshot of Ptolemy is identifying someone to prepare and validate the  
snapshots for this purpose (i.e., not test Ptolemy as such, but the  
view of Ptolemy represented to the build system and default  
configuration of it).  And that with Kepler 2.0 out the number of  
people who would even know that the kepler trunk depends on the  
Ptolemy trunk will be smaller (and might not include me). Finally, if  
we did use snapshots of Ptolemy, I think we'd need to synchronize with  
Ptolemy a lot more often than once a month, for all the reasons you  
give.

In the meantime, I wonder what people (like me) should be building  
against when developing modules (like comad) we hope to have work with  
Kepler 2.0?  Until there is a better way, I'm going to keep working at  
the trunk (of both) and asking questions on irc when things don't  
work, which means others are going to spend considerable time tracking  
down these issues.

Cheers,

Tim

On May 14, 2009, at 4:19 PM, Matt Jones wrote:

> David,
>
> Thanks for the thoughtful note.  We have discussed this issue a number
> of times over the last few years. In general, results from previous
> discussions agreed with your conclusions that a stable development
> platform is important.  We even were working off of a ptolemy snapshot
> for the first two years or so, but ultimately switched to the trunk
> when we determined that the periodic sync activity with the ptolemy
> trunk was not happening, mainly due to lack of an identifiable person
> to follow through on the sync.  So, the difficult issue that has
> always prevented us from using snapshots is determining who is
> responsible for these roughly monthly updates.  While Kepler/CORE is
> funded, we can fund infrastructure work like this off of that.  But in
> a year or so when we only have external-project developers, can we be
> sure someone will sync the snapshot with the ptolemy trunk?  If not,
> we will steadily drift out of sync, and future improvements and fixes
> to ptolemy become that much more difficult to incorporate.  The longer
> the time between syncs, the harder it is to sync.  Nightly builds
> against the ptolemy trunk ensure that we continue to be able to sync.
>
> One way to view this is that the new release process with its
> associated teams based on our new module system will create a stable
> development point for people who want or need that.  Once we start
> making real module releases with Kepler 2.0.0, anyone who wants
> uninterrupted development time without distractions from trunk changes
> would simply use a release as their development point.  They would be
> unaffected by changes in the trunk.  Other developers, such as those
> responsible for maintaining the kepler 'kernel' modules, would
> presumably work off of the trunk, syncing with ptolemy until any new
> changes are working properly, then release new versions of the kepler
> and ptolemy kernel modules.  These would then be the basis for the
> next full kepler release, at which point other extension developers
> would be able to leapfrog ahead and start developing against the newly
> released, and stable, version of kepler.  In this scenario, we do
> snapshot ptolemy as a module each time we want to release a new
> version of the kernels that depend on ptolemy. Maybe it should be the
> Build and Release team's job to propose when new releases of the
> kepler kernel modules and ptolemy module are needed?
>
> This approach allows us to both have a stable set of modules for
> developers that minimizes disruptions and to keep the trunk relatively
> synchronized with ptolemy so that we don't again drift out of sync.
>
> Matt
>
>
> On Thu, May 14, 2009 at 2:44 PM, David Welker <david.v.welker at gmail.com 
> > wrote:
>> Hi all,
>>
>> I wanted to see how people felt, including people working on  
>> Ptolemy, about
>> the following proposal. Instead of having the trunk of Kepler run  
>> off the
>> trunk of Ptolemy, instead we should have it run off a snapshot or  
>> release of
>> Ptolemy. Then, according to a set schedule, Kepler could  
>> synchronize the
>> trunk of Kepler with the trunk of Ptolemy. This way, we can remain  
>> highly
>> coordinated with Ptolemy and the Ptolemy community, but not be  
>> impacted by
>> minor (yet important) changes.
>>
>> Overall, I am really impressed with how stable the trunk of Ptolemy  
>> is.
>> Compilation problems and problems running are usually resolved  
>> quickly.
>> However, sometimes, things are not so easy and it isn't anyone's  
>> fault.
>> There are just too many moving parts.
>>
>> I think today was a case in point. The build continues to evolve,  
>> as it
>> must. Modules that depend on the build, such as loader and module- 
>> manager,
>> also continue to evolve. Ptolemy continues to evolve. All of this  
>> evolution
>> is absolutely necessary. But, it also conflicts with another need  
>> we have,
>> and that is a stable foundation upon which developers can work.
>>
>> Here is the story of what happened today:
>>
>> Ptolemy decided to move some configuration files --  
>> gtEffigyFactory.xml and
>> gtTableauFactory.xml -- from one location to another. Specifically,  
>> from
>> ptolemy/configs/gt/ to ptolemy/configs/. This strikes me as a  
>> perfectly
>> sensible change. But, it also was pretty expensive in terms of  
>> developer
>> time. Unfortunately, our configuration.xml file in Kepler referred  
>> to the
>> old location of these files instead of the new locations.
>>
>> It took me at least 3 hours to find this problem. Not least of which,
>> because these changes in Ptolemy corresponded with significant  
>> changes I
>> have been making to loader and module-manger, not to mention the  
>> build. When
>> so many things are changing at once, it is challenging to isolate  
>> an error
>> like this. I spent a significant amount of time looking for how the  
>> build
>> system or loader was somehow causing this error, when in fact it  
>> was a
>> change in ptolemy without a corresponding change to a configuration  
>> file
>> that was the real culprit.
>>
>> Of course, the amount of time it took me to find this error is only  
>> a small
>> part of the cost. I think this change happened sometime yesterday.  
>> I didn't
>> run into this error until I updated. It basically broke Tim's build
>> yesterday, and at some point he had to stop working. I know it also  
>> broke
>> Aaron's build too. So, we have what turns out to be a rather minor  
>> (yet
>> important) change sucking up multiple hours for multiple  
>> developers. It
>> seems pretty clear that the decision to synchronize the trunk of  
>> Kepler with
>> the trunk of Ptolemy in real time is pretty expensive. So, we  
>> really have to
>> scrutinize this decision.
>>
>> Imagine a world where, instead of working off the trunk of Ptolemy,  
>> we work
>> off a snapshot that is made on a regular basis, say once a month.  
>> When we
>> decide to migrate the trunk of Kepler to work with the trunk of  
>> Ptolemy on a
>> monthly basis, if we found that Kepler suddenly stopped working, we  
>> would
>> immediately know where the problem was. There must have been a  
>> change in
>> Ptolemy that made it incompatible with Kepler. So, this sort of  
>> problem
>> would take much less time to hunt down, simply out of virtue that  
>> the set of
>> potential causes would be much smaller. Secondly, and more  
>> significantly,
>> the costs of such incompatibilities could be absorbed by one expert  
>> who
>> would be well equipped to figure out how compatibility was breaking  
>> down,
>> rather than subset of the entire Kepler community that chooses to  
>> work off
>> the trunk of Kepler. Only when compatibility was ensured would a new
>> snapshot that reflected the latest trunk of Ptolemy be used.
>>
>> I don't really see any downsides to this proposal. We would still  
>> be working
>> in a very collaborative manner with Ptolemy. Only, the costs of such
>> collaboration would be much lower.
>>
>> Does anyone else have any thoughts on this proposal?
>>
>> David
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>
>
>
>
> -- 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Matthew B. Jones
> Director of Informatics Research and Development
> National Center for Ecological Analysis and Synthesis (NCEAS)
> UC Santa Barbara
> jones at nceas.ucsb.edu                       Ph: 1-907-523-1960
> http://www.nceas.ucsb.edu/ecoinfo
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev