Re: [PORTS] RedHat6.0 & Alpha

On Fri, 30 Jul 1999, Thomas Lockhart wrote:

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

Ok, you lost me on the terminology there then. What exactly is
'back-patching'?

> 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 do follow your logic on a stable vs. unstable tree, and can see
the benefit of having it.

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

Yea, it has been like that with the Linux/Alpha port for some
time, including other packages then pgsql alone. :( As for the other Alpha
stakeholders, I have yet to hear from any of them at all in this
disscussion and for a while in any discussion concerning pgsql and
Linux/Alpha. Of course, every now and then, some Linux/Alpha user comes
along and asks why we haven't moved anywhere with pgsql in the last so
long, and gets mad with any answer I try and give them. My conclusion
about Linux/Alpha is that lots of people want the power of the alpha
processor, but don't want to help out and get rid of some of the lingering
sharp edges. They want it to work right out of the box! That leaves things
to a few of us die hards to get everything working, and most of them
focus on more fundamental things, like gcc and glibc, and the applications
end up getting the short end of the stick. Ok, I will get off my soap box
here, back to the trenches....

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

After this discussion and a few tests of my own, I think I had
better change my position on this issue.
First of all, today's snapshot with Uncle G's patches compiles and
runs on Linux/Intel and Solaris/Sparc as well as they do without the
patches on the same snapshot for the most part. Though the patches seem to
break the random regression test on Linux/Intel. Also, today's snapshot
(clean) will not compile on Solaris/Sparc, as there is an extra #endif in
./src/backend/port/isinf.c that gcc on Solaris pukes on. :(
So, this snapshot is in suspect, and it looks like the alpha
patches are as well, at least as far as other platforms go.
My vote would be go back and do a 'alpha' patch off of 6.5.1, and
distribute that to the distribution people to get pgsql running on
Linux/Alpha in the short time. Then, four months or so down the road when
the next release target comes up, we plan to have a version of pgsql that
will run on both Alpha and other platforms. That means Uncle G's patches
need to be checked for what they do to the other platforms.
This would get us a Alpha ready version of pgsql now (there has
been enough delay as it is, we really don't want to wait any more), not
put us out on the limb with a possibly unstable release of pgsql, and
gives us time to get the alpha patches properly tested and integrated into
the main source tree.
As I see it, these are the following things that need to be added
to 6.5.1 to make it alpha ready:

* Uncle G's Alpha patches { which I have }.
* Makefile conditionals for Linux/Alpha { which I can find with
only moderate trouble }.
* Bruce's alignment patches { which I do not have }.

Bruce, if you could get me your alignment patches, then I will try and
apply the above to 6.5.1, and make a patch that bring 6.5.1 up to alpha
ready state. Then we give that patch to debian and RH developers, tell
them to only apply it to thier alpha builds, and that we will have a
universal source tree for all platforms (including alpha) in a few months.
This is simular to what was done (might even still be done) for
the Linux kernel itself. To compile a 2.0.x kernel for Linux/Alpha, one
got the clean source, a set of alpha patches for the same rev level, and
applied them to the clean source to generate an alpha ready kernel source
tree.
Is this a viable idea, or just another horrible kludge?

> My $0.03 ;)

Raising the ante here? :) Well, then this was my four cents!

----------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
----------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | rkirkpat(at)nag(dot)cs(dot)colorado(dot)edu |
----------------------------------------------------------------------------
| http://www-ugrad.cs.colorado.edu/~rkirkpat/ |
----------------------------------------------------------------------------