7.2b1 ...

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

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

On Thu, 25 Oct 2001, 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?

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

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

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

...

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

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

...

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

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

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

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

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

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

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

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