Re: [HACKERS] Re: [PORTS] RedHat6.0 & Alpha

I do not want to see any patches commit'd to v6.5.x branch that is
*anything* but a minor bug fix...personally, we had a 2 month beta period
on this...the Alpha related stuff should have been submit'd then, at the
very latest...

Please feel free to work at getting these into v6.6, *before* v6.6 is
released, so that this problem doesn't rear its head again...

On Thu, 29 Jul 1999, Ryan Kirkpatrick wrote:

> 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@nag.cs.colorado.edu  |
> ----------------------------------------------------------------------------
> |               http://www-ugrad.cs.colorado.edu/~rkirkpat/                |
> ----------------------------------------------------------------------------
>
>
>

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org