[ruby-core:17189] Re: REXML Separation

(Sam, I also address your response at the bottom of this email)

On Tuesday 10 June 2008, Federico Builes wrote:
> As most of you may know, REXML's currently using a different bug
> tracker and source control tree.
>   I'd like to know what's the rationale behind having this, is there
> a major reason not to merge that (or at least, the bug tracker) into
> SV/the new Redmine installation?

The rational is that, long before REXML was distributed with Ruby, it=20
was an external library.  The existing repository has a long history,=20
and the bug tracker was much better than Ruby's (prior to Redmine). =20
Trac isn't significantly better than Redmine, so the two issues that I=20
see are:

1. The pain of converting the existing REXML bug database to the Ruby=20
databes,
2. The loss of bug history
3. The fact that the REXML repository contains more data than is=20
currently in Ruby.

Currently, REXML exists in the Ruby repository as a library, and only a=20
library.  I recently performed work to pull all of the REXML unit tests=20
into the Ruby repository and merge them, but I haven't merged that=20
branch with any of the main branches yet.  There is also a bunch of=20
other development-related code (benchmarks, documentation sources,=20
etc.) that isn't in the Ruby codebase... so point (3) boils down to=20
figuring out how to merge everything that's currently in the REXML repo=20
into the Ruby repo.

> I think it'd benefit everyone on several levels:
>
> - Centralized spots for bugs. Users don't have to create a new Trac
> account on Germane Software's tracker to submit a patch.

Agreed, this would be nice.

> - Anyone with commit access to Ruby's SVN can fix small bugs, making
> the job easier for SER (Sam Ruby(?)) and for everyone really. This
> leads to faster issue fixes.

As it turns out, people modify the REXML sourcecode in the Ruby repo=20
fairly often, and I merge those changes into the REXML repo and keep=20
those in sync.  You're right that it would be easier for Sam and I, but=20
I doubt that it would lead to faster issue fixes.

One thing that I've struggled with is the distinction between what is a=20
bug, and what is simply preference.  At least once in REXML's history,=20
it went through several iterations where it the behavior of the=20
pretty-printer oscilatted between two or three behaviors simply because=20
three different people thought that their preferred behavior was=20
correct, and everything else was a bug.  Furthermore, the XML spec=20
doesn't help this situation; IME, it is easy to quote it out of context=20
and interpret incorrect behavior.  This is slightly off-topic, though;=20
there is advantage to having REXML's main repo be the Ruby repo, and=20
I've considered it before.

> - No more version difference between the official REXML release and
> the one included in Ruby.

This won't happen even if REXML is maintained in the Ruby repository.  I=20
will always do my work in a branch and then merge into main.  I've=20
always been shy of changing the distributed Ruby code, and even this=20
level of hesitance hasn't been enough as can be seen from a few of the=20
regressions that have gone out with official releases.

> - Rubyspec testing in the latest trunks (no more typo bugs, see
>    document.rb:80 in Ruby 1.9 or the trans vs. transitive issue).

Exactly my previous point.  This was a regression bug, not a typo bug,=20
so integrating won't help this.

In any case, now that the bug tracker is Redmine, I'm more willing to=20
consider it.  I just need to find a place to put the REXML-specific=20
development tools in the repository (benchmarks/, bin/, contrib/,=20
docs/, styles/, etc.).

Sam, if you have any suggestions about how to convert the Trac DB to=20
Redmine while maintaining history, or if you have any suggestions about=20
how to fit the REXML code into the Ruby repo, please let me know.  I=20
*would* like to consider this move, but I want to have a well-defined=20
migration plan.

=2D-=20
=2D-- SER