Horton

Thread

  1. 7.2b1 ...

    Marc Fournier <scrappy@hub.org> — 2001-10-25T16:48:08Z

    ... is now packaged ... mirrors will pick it up soon, but if anyone wants
to do a quick check, its in /pub/beta ...

  2. Re: 7.2b1 ...

    Peter Eisentraut <peter_e@gmx.net> — 2001-10-25T18:41:44Z

    Marc G. Fournier writes:

> ... is now packaged ... mirrors will pick it up soon, but if anyone wants
> to do a quick check, its in /pub/beta ...

What ever happened to 7.2beta1?

Sorry, but the inconsistency in naming of releases and CVS tags (if ever
there would be any) is driving me nuts.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  3. Re: 7.2b1 ...

    Marc Fournier <scrappy@hub.org> — 2001-10-25T19:13:58Z

    CVS tags have been conssitent since v7.1 ...


On Thu, 25 Oct 2001, Peter Eisentraut wrote:

> Marc G. Fournier writes:
>
> > ... is now packaged ... mirrors will pick it up soon, but if anyone wants
> > to do a quick check, its in /pub/beta ...
>
> What ever happened to 7.2beta1?
>
> Sorry, but the inconsistency in naming of releases and CVS tags (if ever
> there would be any) is driving me nuts.
>
> --
> Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter
>
>

  4. Re: 7.2b1 ...

    Peter Eisentraut <peter_e@gmx.net> — 2001-10-26T18:41:16Z

    Marc G. Fournier writes:

> CVS tags have been conssitent since v7.1 ...

Allow me to consider that a joke:

REL7_2_BETA1
REL7_1_STABLE
REL7_1_BETA3
REL7_1_BETA2
REL7_1_BETA
REL7_1_2
REL7_1

So,

Where is REL7_1_1?  Where is REL7_1_BETA1?  What does REL7_1_BETA belong
to?  What ever happened to beta4 thru beta6 or so, and rc1 through rc3?
What is the CVS tag for 7.2b1?  What release is the tag REL7_2_BETA1 for?

And if there is a 7.2b1, where is 7.2a1?  And do you realise that in the
GNU tradition, a release 7.2b would be a beta release leading to 7.3?

And I won't even start talking about the names of the ChangeLog files
which are fortunately gone.

All of this requires just a minute of thought and will save countless
people a headache.

Please.


>
>
> On Thu, 25 Oct 2001, Peter Eisentraut wrote:
>
> > Marc G. Fournier writes:
> >
> > > ... is now packaged ... mirrors will pick it up soon, but if anyone wants
> > > to do a quick check, its in /pub/beta ...
> >
> > What ever happened to 7.2beta1?
> >
> > Sorry, but the inconsistency in naming of releases and CVS tags (if ever
> > there would be any) is driving me nuts.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  5. Re: 7.2b1 ...

    Hannu Krosing <hannu@tm.ee> — 2001-10-26T20:14:29Z

    Peter Eisentraut wrote:
> 
> Marc G. Fournier writes:
> 
> > CVS tags have been conssitent since v7.1 ...
> 
> Allow me to consider that a joke:
> 
> REL7_2_BETA1
> REL7_1_STABLE
> REL7_1_BETA3
> REL7_1_BETA2
> REL7_1_BETA
> REL7_1_2
> REL7_1
> 
> So,
> 
> Where is REL7_1_1?  Where is REL7_1_BETA1?  What does REL7_1_BETA belong
> to?  What ever happened to beta4 thru beta6 or so, and rc1 through rc3?
> What is the CVS tag for 7.2b1?  What release is the tag REL7_2_BETA1 for?

You could also consider the above as an IQ test ;)

> And if there is a 7.2b1, where is 7.2a1?  And do you realise that in the
> GNU tradition, a release 7.2b would be a beta release leading to 7.3?

And in linux kernel tradition there would be no non-beta 7.3 and the
beta 
for 7.2 would be 7.1.299 or something, and there would also be numerous 
"brown paper bag" releases ;)

> And I won't even start talking about the names of the ChangeLog files
> which are fortunately gone.
> 
> All of this requires just a minute of thought and will save countless
> people a headache.

As the result of "a minute of thought" is heavily dependent of the
thinker
I suggest that you do a writeup of yours, enumerating the rules for both 
internal (code and CVS tags) and external development, alpha, beta and
release
numbering and naming as well as rules for when and how to apply them.

If you come up with something that all thinkers can agree, I'm sure it
will 
be used from now on.

--------------------
Hannu

  6. Re: 7.2b1 ...

    Lamar Owen <lamar.owen@wgcr.org> — 2001-10-26T23:42:53Z

    On Friday 26 October 2001 04:14 pm, Hannu Krosing wrote:
> And in linux kernel tradition there would be no non-beta 7.3 and the
> beta
> for 7.2 would be 7.1.299 or something, and there would also be numerous
> "brown paper bag" releases ;)

We have had our share of 'brown paper bag' releases, too.  And they serve a 
useful purpose -- keeping us on our toes and reminded that even the best and 
brightest open source development team around can make mistakes.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  7. Re: 7.2b1 ...

    lockhart@fourpalms.org — 2001-10-27T00:32:51Z

    ...
> If you come up with something that all thinkers can agree, I'm sure it
> will be used from now on.

I *think* that somewhere there is a list of "things to do" to prepare a
release. If that isn't in the sgml doc set, it should be. And if it
doesn't mention the naming convention for beta and release labels, it
should.

Peter or someone, do you want to collect that stuff (with useful
additions) and make a chapter or appendix in the developer's docs?

                       - Thomas

  8. Re: 7.2b1 ...

    Lamar Owen <lamar.owen@wgcr.org> — 2001-10-27T01:04:54Z

    On Thursday 25 October 2001 12:48 pm, Marc G. Fournier wrote:
> ... is now packaged ... mirrors will pick it up soon, but if anyone wants
> to do a quick check, its in /pub/beta ...

Attempting to build an initial RPMset here.... Will upload when I get a good 
build -- although I may have to release without the contrib tree packaged, 
due to build errors.

Stay tuned for the latest.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  9. Re: 7.2b1 ...

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-10-27T01:38:40Z

    > ...
> > If you come up with something that all thinkers can agree, I'm sure it
> > will be used from now on.
> 
> I *think* that somewhere there is a list of "things to do" to prepare a
> release. If that isn't in the sgml doc set, it should be. And if it
> doesn't mention the naming convention for beta and release labels, it
> should.

It is tools/RELEASE_CHANGES.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  10. Re: 7.2b1 ...

    bpalmer <bpalmer@crimelabs.net> — 2001-10-27T23:32:24Z

    Is there some formal place to make comments on how 7.2b1 works?  I'm about
to run it through it's paces on OBSD.  Or is this just a 'it's broked'
testing time?

- Brandon

----------------------------------------------------------------------------
 c: 646-456-5455                                            h: 201-798-4983
 b. palmer,  bpalmer@crimelabs.net           pgp:crimelabs.net/bpalmer.pgp5

  11. Re: 7.2b1 ...

    Peter Eisentraut <peter_e@gmx.net> — 2001-10-28T12:30:17Z

    Hannu Krosing writes:

> You could also consider the above as an IQ test ;)

The only problem is that computers have been shown to have an IQ of zero.

> I suggest that you do a writeup of yours, enumerating the rules for
> both internal (code and CVS tags) and external development, alpha,
> beta and release numbering and naming as well as rules for when and
> how to apply them.

The rules have been the same for as long as memory serves.  The
development tree is first labeled as betaX for a few consecutive X, then
rcX a few times, then follows a release, and the numbering scheme of the
releases is well known.  We've more recently introduced labeling the
development tree itself as "devel".

The problem appears to be that the people that perform these actions do
not fully understand the scope of the issues the come with those actions,
and therefore perform them carelessly.  (If you don't believe "careless",
the commit message that changed the version to 7.2b1 is less than one line
and contains two obvious spelling mistakes.)

For example, release numbers ought to sort lexicographically.  There are
just too many tools that would prefer this.  Yet, this issue is ignored
completely.

Release making should be reproduceable -- without race conditions.  This
would at least require a CVS tag for every release, and a reliable way to
package the documentation with the rest of the source.

People need to understand the meaning of the release names.  There are
obviously way too many release numbering schemes out there, few of which I
like.  But in the history of PostgreSQL, there has never been a release
called X.Yb1.  I have currently no confidence that the next release won't
be called X.YBeta2, to mess up all chanced of anything sorting correctly.

In a sense, making a release is a change in the source code, and if it's
done in novel ways it should be discussed first.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  12. Re: 7.2b1 ...

    Peter Eisentraut <peter_e@gmx.net> — 2001-10-28T12:31:17Z

    Lamar Owen writes:

> Attempting to build an initial RPMset here.... Will upload when I get a good
> build -- although I may have to release without the contrib tree packaged,
> due to build errors.

Did you get all the patches I sent you?  These should have the contrib
tree covered.  If you plan to release the "initial" RPM set without
anything remotely similar to those patches you'll probably run into a
boatload of problems.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter

  13. Re: 7.2b1 ...

    Lamar Owen <lamar.owen@wgcr.org> — 2001-10-29T20:44:12Z

    On Sunday 28 October 2001 07:31 am, Peter Eisentraut wrote:
> Lamar Owen writes:
> > Attempting to build an initial RPMset here.... Will upload when I get a
> > good build -- although I may have to release without the contrib tree
> > packaged, due to build errors.

> Did you get all the patches I sent you?  These should have the contrib
> tree covered.  

Got them; applied them; tweaked them (not involving contrib); got the 
following:

make[1]: Entering directory 
`/usr/src/redhat/BUILD/postgresql-7.2b1/contrib/fuzzystrmatch'
sed 's,MODULE_PATHNAME,$libdir/fuzzystrmatch,g' fuzzystrmatch.sql.in 
>fuzzystrmatch.sql
gcc -O2 -march=i386 -mcpu=i686 -Wall -Wmissing-prototypes 
-Wmissing-declarations -fpic -I. -I../../src/include -I/usr/kerberos/include  
-c -o fuzzystrmatch.o fuzzystrmatch.c
fuzzystrmatch.c: In function `_metaphone':
fuzzystrmatch.c:345: parse error before `return'
make[1]: *** [fuzzystrmatch.o] Error 1
make[1]: Leaving directory 
`/usr/src/redhat/BUILD/postgresql-7.2b1/contrib/fuzzystrmatch'
make: *** [all] Error 2

Looking at it, but with a transmitter not running right here it could be a 
few days before I get back to it.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  14. Re: 7.2b1 ...

    Tom Lane <tgl@sss.pgh.pa.us> — 2001-10-29T21:58:35Z

    Lamar Owen <lamar.owen@wgcr.org> writes:
> gcc -O2 -march=i386 -mcpu=i686 -Wall -Wmissing-prototypes 
> -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/kerberos/include 
> -c -o fuzzystrmatch.o fuzzystrmatch.c
> fuzzystrmatch.c: In function `_metaphone':
> fuzzystrmatch.c:345: parse error before `return'
> make[1]: *** [fuzzystrmatch.o] Error 1
> make[1]: Leaving directory 
> `/usr/src/redhat/BUILD/postgresql-7.2b1/contrib/fuzzystrmatch'
> make: *** [all] Error 2

This is a bug introduced by Bruce's recent pgindent run, not an RPM
packaging issue.  I believe the fix is in CVS already.

			regards, tom lane

  15. Re: 7.2b1 ...

    Lamar Owen <lamar.owen@wgcr.org> — 2001-10-29T22:29:01Z

    On Monday 29 October 2001 04:58 pm, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > gcc -O2 -march=i386 -mcpu=i686 -Wall -Wmissing-prototypes
> > -Wmissing-declarations -fpic -I. -I../../src/include
> > -I/usr/kerberos/include -c -o fuzzystrmatch.o fuzzystrmatch.c
> > fuzzystrmatch.c: In function `_metaphone':
> > fuzzystrmatch.c:345: parse error before `return'
> > make[1]: *** [fuzzystrmatch.o] Error 1
> > make[1]: Leaving directory
> > `/usr/src/redhat/BUILD/postgresql-7.2b1/contrib/fuzzystrmatch'
> > make: *** [all] Error 2

> This is a bug introduced by Bruce's recent pgindent run, not an RPM
> packaging issue.  I believe the fix is in CVS already.

Ok.

I'll patch only what I have to patch to get a build of 7.2b1, or I might as 
well call any resultant RPMset postgresql-7.x.cvs20011029 or somesuch.

At least it was something simple.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

  16. Re: 7.2b1 ...

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-10-30T02:37:03Z

    > Lamar Owen <lamar.owen@wgcr.org> writes:
> > gcc -O2 -march=i386 -mcpu=i686 -Wall -Wmissing-prototypes 
> > -Wmissing-declarations -fpic -I. -I../../src/include -I/usr/kerberos/include 
> > -c -o fuzzystrmatch.o fuzzystrmatch.c
> > fuzzystrmatch.c: In function `_metaphone':
> > fuzzystrmatch.c:345: parse error before `return'
> > make[1]: *** [fuzzystrmatch.o] Error 1
> > make[1]: Leaving directory 
> > `/usr/src/redhat/BUILD/postgresql-7.2b1/contrib/fuzzystrmatch'
> > make: *** [all] Error 2
> 
> This is a bug introduced by Bruce's recent pgindent run, not an RPM
> packaging issue.  I believe the fix is in CVS already.

Yes, fixed today.  It was a macro that was called with no trailing
semicolon.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026