[kepler-dev] Quick comment on diagnosing problems in Kepler and making your life a little easier.

[David Welker]

Today, a couple of bug entries were made that suggested (incorrectly, it
turns out) that the build system was causing problems with Kepler. I think
this illustrates a general problem, and that is in a complex software system
like Kepler, it is difficult to determine the origins of problems. The build
system does evolve, and so it is therefore a natural suspect when things go
wrong.

In general, if you encounter a new error that you did not encounter before,
there are four possible sources. (1) It could be a change in the build
system. (2) It could be an error in code you are developing in your own
modules. (3) It could be an error in code someone else is developing in
modules you depend on. (4) It could be a change to your system
configuration, such as what version of Java or Ant you are using.

How do you go about narrowing this list?

First, if you haven't changed your system configuration such as what version
of Java or Ant you are using, you can generally eliminate this as a
possibility.

Second, when you develop new modules, you have a decision to make. Do I want
to work from the trunk of Kepler and Ptolemy, or do I want to work from a
particular version, such as those used in the release of 1.0. In general, if
you decide to work from the trunk of Kepler and Ptolemy, you are making
yourself vulnerable to the changes of quite a few other people. A change in
Ptolemy could break you. A change by someone else in one of the core modules
could break you. Basically, in my view, unless you have a really good reason
to be working at the trunk, I would highly recommend that you avoid doing
so. But, if you do decide to work from the trunk, you should realize that
your first suspect with problems probably shouldn't be the build system, it
should be the other developers who are working on modules that you have
decided to depend on.

If, instead of working at the trunk, you work against 1.0 (and in the
future, another "frozen" release of Kepler) and you are not changing basic
elements of your system configuration (such as what version of Java your
using) then when problems arise, you know that it is either (1) your own
code, (2) the build system, or (3) the loader module, which is a module that
everyone depends and that might change under you. In general, it is my plan
to be fairly cautious (more cautious than I have been before now) before
committing changes to the build system or the loader module so as to
maximize stability for those who work against 1.0. I will also carefully
monitor any changes that anyone else decides to make to either the build
system or the loader module.

Anyway, I just really think that anyone who is working at the trunk should
strongly consider working against 1.0 if they want to minimize headaches.
When a bunch of people are working against and changing modules that
constitute the common core of Kepler, you are going to be stepping on each
others toes. I could illustrate this with recent examples, but I prefer to
keep this discussion more abstract.

If you do decide to work at the trunk of Kepler, errors are thus most likely
going to be either from (1) your own code or (2) from one of the many
modules that you depend on that has been modified by someone else,
especially going forward as I take a more conservative approach with changes
to the build and to the loader module.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20090122/00ec2bab/attachment.html>