[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 
was an external library.  The existing repository has a long history, 
and the bug tracker was much better than Ruby's (prior to Redmine).  
Trac isn't significantly better than Redmine, so the two issues that I 
see are:

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

Currently, REXML exists in the Ruby repository as a library, and only a 
library.  I recently performed work to pull all of the REXML unit tests 
into the Ruby repository and merge them, but I haven't merged that 
branch with any of the main branches yet.  There is also a bunch of 
other development-related code (benchmarks, documentation sources, 
etc.) that isn't in the Ruby codebase... so point (3) boils down to 
figuring out how to merge everything that's currently in the REXML repo 
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 
fairly often, and I merge those changes into the REXML repo and keep 
those in sync.  You're right that it would be easier for Sam and I, but 
I doubt that it would lead to faster issue fixes.

One thing that I've struggled with is the distinction between what is a 
bug, and what is simply preference.  At least once in REXML's history, 
it went through several iterations where it the behavior of the 
pretty-printer oscilatted between two or three behaviors simply because 
three different people thought that their preferred behavior was 
correct, and everything else was a bug.  Furthermore, the XML spec 
doesn't help this situation; IME, it is easy to quote it out of context 
and interpret incorrect behavior.  This is slightly off-topic, though; 
there is advantage to having REXML's main repo be the Ruby repo, and 
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 
will always do my work in a branch and then merge into main.  I've 
always been shy of changing the distributed Ruby code, and even this 
level of hesitance hasn't been enough as can be seen from a few of the 
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, 
so integrating won't help this.

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

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

-- 
--- SER