Re: [rvm-core] Integration of RDB in Jikes RVM

[Erik B. <eri...@gm...>]

Hi,

On 09.10.2013 10:34, Dmitri Makarov wrote:
> RDB doesn't use any license. We can pick any license that is compatible with Jikes RVM project

I'm not quite sure if there's any freedom of choice for the license. The Eclipse Public License (which the Jikes RVM uses) says that derivative works must be licensed under the EPL. IANAL so I don't know whether RDB constitutes a derivative work.

> or we can transfer the ownership of RDB to Jikes RVM project. 

What do you mean by ownership? My understanding is that we don't provide any means to assign copyrights to "the project" and we don't have any backing legal entity that could take them.

> b) Jikes RVM Linux build includes building RDB. 

The build on linux does not succeed out of the box on my machine:

viewer-native-library:
     [exec] gcc: error: tools/native/host/posix/mach.c: No such file or directory
     [exec] gcc: error: tools/native/host/posix/util.c: No such file or directory

> In fact even now RDB can be used on Linux as RVM boot image viewer. 

How do I configure a fresh checkout of the rdb repository on Linux to do this?

> [..] We currently don't have automated tests for testing RDB, but I believe it is important to add such tests.

IMHO the testing situation in the Jikes RVM project is already bad enough. I'd rather not merge code that is not covered by tests at all. Even some simple tests (e.g. smoke tests) would be beneficial.

> The missing part is the code that interacts with a running RVM process. We plan to implement this, but we can't guarantee how soon this will be done.

I don't like the idea of having RDB in the code base without full Linux support because I suspect that Linux is the most widely used operating system for development of the RVM.

> The integration process should be no more complex than applying a patch that we'll submit.

IMHO using a single patch has too much disadvantages (e.g. big bang integration, hard to review, no history). A set of patches that replay the development of RDB as it would have occurred with out dead ends would be much better. This should be done in the form of Mercurial changesets with useful commit messages.

You'll need to decide on the coding style that RDB should use. The build is currently not set up to exclude RDB from the set of files that are subject to Checkstyle which means it will fail if Checkstyle is enabled (as is the case during test runs). Package-level Javadoc comments would also be nice.

It would also necessary to update the user guide.


Kind regards,

Erik Brangs