> > IMHO a 6.5.2 release with all of the necessary alpha patches
> > already in the distribution source tree is a much cleaner, clearer
> > solution, for distribution packagers, average users, and
> > compile-it-yourself-people.
> I think he was going to generate a 6.5.2 by back-patching, not
> distributing a new patch to make 6.5.2.
Yup.
OK, I'm trying to do this to help the Alpha folks, in such a way that
it helps the Alpha-linux-RH folks to get RPMs also. Having a 6.5.2
which does not run on Intel or Sparc does not help. Having a 6.5.2
which has diverged from the 6.5.x tree in unknown ways does not help.
Having us decide by consensus the appropriate model for s/w
development (main tree with changes progressing to a full release,
branch tree to carry maintenance changes) and then at the first
opportunity step away from that seems counterproductive in the
extreme. We ran into this same discussion during v6.4.x, and we're
doing it again.
If y'all can't maintain two branches, then let's stop doing it. otoh,
we can't do maintenance releases without a stable branch, so we'd
better think about it before giving up.
I've offered to help, much more than I should bother with. I'll leave
it to other Alpha stakeholders to decide what they want. I should
point out that I offered to our RedHat contacts to try to marshall an
Alpha-ready build, but so far it's like herding cats.
And *really*, if we have 3.5MB of diffs, who are we kidding about
knowing where they all came from and what they are doing? Backpatching
or developing patches on a clean 6.5.1 release is the only thing to do
for a 6.5.2. Otherwise, call it 6.6-prealpha and we'll wait 4 months
for RPMs.
My $0.03 ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California