Thread: 7.2b1 ...
... is now packaged ... mirrors will pick it up soon, but if anyone wants to do a quick check, its in /pub/beta ...
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: > > > ... 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 > >
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, Pennsylvania19026
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-4983b. 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, Pennsylvania19026