[kepler-dev] Proposed Use Cases for New Build System
tmcphillips at mac.com
Mon Apr 14 08:30:21 PDT 2008
Yes, let's all wait for feedback from everyone on how much work the
licensing issues for compile-time dependencies would be to resolve
before researching the other licenses.
Going over the Kepler/CORE build system use case proposals today
sounds good, but here are few quick comments. First, let's create a
separate document listing a number of different options for how Kepler
could conceivably depend on Ptolemy at compile time. This will allow
folks to point out pros and cons of each approach (and additional
alternatives). Second, let's work on separating out the high-level
system functions from the implementation (and policy) proposals (the
"wills" and "shoulds"). This will allow us to distinguish
conversations about what functions and system characteristics we want
to support from how one might achieve them, encourage others to
propose different priorities, approaches, etc. I think the current
document can serve as seed and source material for these analyses.
Take the proposal to remove build- and run-time dependencies on
environment variables, for example. If we phrase the desideratum
behind this as "support cross-platform, cross-tool (including multiple-
IDE) development with minimal configuration", it will be clearer
whether the ultimate goal is achievable and suggest what else would
have to be done.
Thanks for doing this!
On Apr 14, 2008, at 6:23 AM, David Welker wrote:
> Hi Timothy,
> I did not work on licensing very much this weekend, although I now
> have a new master spreadsheet that lists all 130 third-party jars
> that Kepler theoretically depends on and I have started the
> painstaking task of hunting down the licenses for the run-time
> dependencies. I figured that it would be better to wait and see if
> what we have already found is a big enough problem that we have to
> restrict the licensing of the release to non-profit users. In some
> sense, that may be the better way to go, as it will allow us to push
> this release out the door and concentrate on defining a well-managed
> core that we can easily license properly, rather than fighting to
> get a whole lot of code BSD compliant that will be ejected from the
> core in any case.
> Time is of the essence here, and if we make these licensing
> restrictions a release blocker, we may delay this release
> significantly. On the other hand, maybe it is not that much work to
> get all this code, including portions that clearly will not be part
> of the core in the future, BSD-compliant. I think we need to get
> feedback on how much work it will be.
> Anyway, I have spent some time working on the use cases for our new
> proposed build system. It is attached. I would love to get your
> feedback on it today.
> <Proposed Use Cases - New Build System.doc>
More information about the Kepler-dev