[ruby-core:17222] Re: REXML Separation

On Wednesday 11 June 2008, Sam Ruby wrote:
> > 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.

I disagree about the severity of this; there's a lot of information in 
closed bugs, and prudent bug reporters do perform searches before 
submitting new bug reports or feature requests.  If the history exists 
in an entirely different bug tracker, it is much less likely that these 
searches will produce anything useful.

> >> - 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
...
> 1) Why would you ever want to release from a branch?

Because I want to avoid, as much as possible, regressions and new bugs 
in the code that goes out with the official Ruby builds.  People who 
pull REXML independantly because they want some specific bug fix or new 
feature are aware of changes in the library, are explicitely aware that 
there may be changes, are testing their apps, and are providing 
valuable "service" by pre-testing releases before they go into Ruby 
main.  People who get a new version of REXML through "apt-get upgrade" 
or "emerge -uv ruby" are less likely to be concious of potential 
impacts on their deployed applications.  REXML has had occasional 
trouble with me being over-eager in pushing revisions to the Ruby 
repository, and I can only believe that it would get worse without a 
trial period.

My development model has, usually, been (alas, not reliably):

1) Work on REXML version X
2) Release a new version
3) Let the version age for a while version, and fork (1)(X+1)
4) Address any issues in version X, and if everything is fine, then push 
X into Ruby main. 

The times that I haven't done this have almost always resulted in 
issues.

> 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.

I agree with you without reservation.  Hence my position on the previous 
point.

Don't misunderstand me, though.  I'm mostly committed with the 
conversion and integration.

-- 
--- SER