ruby-debug/ruby-debug-base-java maintenance

[John Firebaugh]

I've started to take on some maintenance work for the JRuby version of
ruby-debug-base, which now lives on GitHub:

https://github.com/jruby/jruby-debug

Nick Sieger mentioned that we need to figure out how to get a new java
version of ruby-debug-base released. I think the situation here is
very similar to what the json gem went through a while back: at first
there were two separate repositories, Florian Frank's CRuby version
and Daniel Luz's json-jruby version. It was a headache to try to keep
the gem releases in sync: flori would push a new version of the CRuby
gem, other libraries would add dependencies on that version, and folks
on JRuby would be out of luck until the JRuby version was published
with the same version number. Or, a bugfix would be made in the JRuby
version, but have to wait until a new CRuby version was pushed. I
believe the situation was eventually resolved by merging the JRuby
extension into flori's repository, making it much easier for one
person to simultaneously build and release both C and Java gems.

I propose we do something similar.

* Import the ruby-debug SVN repo to git and put it on github. I
propose making a 'ruby-debug' organization to own it, with all
existing ruby-debug and jruby-debug contributors as members.
* Merge the jruby-debug repository in.
* Always do simultaneous releases of ruby-debug-base and ruby-debug-
base-java from this repo.

This would also take care of the fact that the testing task for jruby-
debug depends on pulling in stuff from the ruby-debug SVN repo in a
way that's currently broken (https://github.com/jruby/jruby-debug/
issues/4).

I can volunteer to do the svn -> git move and jruby merge. In fact,
here's the imported git repo:

https://github.com/ruby-debug/ruby-debug

I tried to clean up the git svn import a little by creating real git
tags and branches for the svn branches that didn't look vestigial
(debug_19 and ver_0_11_0).

Yea or nay? If nay, just let me know and I'll take down the repo. If
yea, I'll start working on merging the jruby repo.

[Rocky Bernstein]

Sounds good to me. Thanks for volunteering to do the import and set up the group.

[John Firebaugh]

I'm looking at merging the ruby-debug and jruby-debug repositories now, and it appears ruby-debug is BSD licensed, while jruby-debug is MIT licensed. I believe these are mutually compatible licenses, but it would simplify things to offer the whole repository under a single license.

If we choose BSD, we would need permission to relicense the jruby-debug code from the jruby-debug committers (Martin Krauskopf, Chris Nelson, Peter Brant, Dennis Ushakov, Nick Sieger, myself).

If we choose MIT, we would need the ruby-debug committers (Rocky, Kent Sibilev, Anders Lindgren).

Any preferences?

[John Firebaugh]

OK, I've done a bunch of maintenance work in the git repo:

- Merged JRuby extension

- Updated to use git2cl to generate ChangeLogs

- Split out emacs interface and TeX manual source to ruby-debug-extra repo

- Updated install documentation to reflect move to git

- Use rake-compiler for extension compilation tasks

Let me know what you think: https://github.com/ruby-debug

I think the main remaining item is to get the tests passing on JRuby. I got as far as getting the test_base task passing, now need to figure out what to do with the other tests. At some point in the past it looks like one could apply a patch file included in the repo that fixed up the input and output scripts to something that worked on JRuby, but the patches no longer apply cleanly and even after updating them, there are still numerous test failures. I will start taking a closer look; any help is welcome.

[Roger Pack]

You may be able to get away without rake-compiler stuff and just force users to use the devkit to compile it:)
-roger

[John Firebaugh]

I think using rake-compiler makes things easier for both maintainers and users. For the JRuby extension, it replaced a lot of ad hoc (and broken) compilation code: https://gist.github.com/1124100

For CRuby, the difference was not that great, but still a net reduction in Rakefile LOC count. And it looks promising as a way of making the Windows cross compilation process easier.

The current version of rake-compiler does have a habit of spitting out warnings in completely benign circumstances; I submitted a pull request to fix that: https://github.com/luislavena/rake-compiler/pull/45

[Roger Pack]

For CRuby, the difference was not that great, but still a net reduction in Rakefile LOC count. And it looks promising as a way of making the Windows cross compilation process easier.

I suppose if you're forced to compile binary distributables for windows for jruby then it would be a net win. Good call.

[John Firebaugh]

On Mon, Aug 8, 2011 at 1:55 PM, Roger Pack <roger...@gmail.com> wrote:

For CRuby, the difference was not that great, but still a net reduction in Rakefile LOC count. And it looks promising as a way of making the Windows cross compilation process easier.

I suppose if you're forced to compile binary distributables for windows for jruby then it would be a net win. Good call. 

Not just windows -- for JRuby the compiled .jar file is for any platform with a Java runtime. And on CRuby, we ship both the regular gem (which is compiled at gem install time) and a win32 version with pre-compiled binaries. Right now it's a multi-step process to cross-compile the Windows binaries and generate the mswin32 gem; with rake-compiler it could be a single rake command.