From: Sam Ruby Date: 2008-06-11T22:21:59+09:00 Subject: [ruby-core:17215] Re: REXML Separation Sean E. Russell wrote: > (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, Based on a quick google search, it appears that Redmine has a TRAC import function, but it is (currently?) limited to importing into an empty Redmine installation. > 2. The loss of bug history That's over stating it. Worst case is that the existing bug history is left where it is, and there is a discontinuity as bug history from here on out is built up in Redmine. I'm sure we could quickly open up new bug reports in Redmine for all remaining open bugs, complete with backpointers to the original bug report. > 3. The fact that the REXML repository contains more data than is > currently in Ruby. That's unfortunate. Frankly, the Ruby repository gets more eyes and attention. > 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. That's a downside of long-living branches. >> 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. +1 >> - 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. I think it would lead to faster issue fixes... and to occasional regressions. The fix to the latter is to increase both the test coverage and the awareness of tests. And the best way to increase the awareness is to migrate the tests. > 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. A REXML spec, however, would help. >> - 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. Two points here. 1) Why would you ever want to release from a branch? 2) No matter what the "official" state is, we need to face the fact that for many people, the bits that actually ship with Ruby 1.8.7 mean much more than what you and I consider to be official. >> - 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. Again, increasing the apparent availability of the tests (by making them more easily runnable by Ruby developers), and by developing a more complete test suite/spec for REXML will 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. I'll openly admit that have less of a vested interest in you in maintaining a coherent history. I'll openly admit that everything is a tradeoff, but to my accounting, moving to Redmine, accepting that the history is disjoint, limiting the effective duration of branches, and focusing on specs would be a net positive. A BIG net positive. To give added urgency, consider http://www.tbray.org/ongoing/When/200x/2008/06/10/RX-Work Note: the continuous integration tests of mine that he points to may simply be the fact that I'm running the wrong tests, or due to a temporary regression in Ruby 1.9 itself. Even if this is the case, it still makes the same point. - Sam Ruby