[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=20
closed bugs, and prudent bug reporters do perform searches before=20
submitting new bug reports or feature requests.  If the history exists=20
in an entirely different bug tracker, it is much less likely that these=20
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
=2E..
> 1) Why would you ever want to release from a branch?

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

The times that I haven't done this have almost always resulted in=20
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=20
point.

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

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