Обсуждение: CVS Branch Tagging...
On Friday morning, I'm going to be tagging the PostgreSQL source tree as
STABLE-6_4, and will be creating a new BETA tar ball.
Normal development will be able to continue, while we will be able to
maintain/fix any bugs from those testing the BETA.
On November 1st, I will be tagging it once more as RELEASE-6_4, which will
allow us to cover over any bugs as reported by those upgrading to v6.4.
Starting Friday, if anyone wants to start adding in any new features or
whatnot, this will be possible...AFTER I post that the tagging is done!!
:)
Marc G. Fournier scrappy@hub.org
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
> > On Friday morning, I'm going to be tagging the PostgreSQL source tree as > STABLE-6_4, and will be creating a new BETA tar ball. > > Normal development will be able to continue, while we will be able to > maintain/fix any bugs from those testing the BETA. > > On November 1st, I will be tagging it once more as RELEASE-6_4, which will > allow us to cover over any bugs as reported by those upgrading to v6.4. > > Starting Friday, if anyone wants to start adding in any new features or > whatnot, this will be possible...AFTER I post that the tagging is done!! > :) While it will be possible, I would like people to concentrate on the existing 6.4 issues we have, and discourage parallel development on separate final and features source trees. If 6.4 is similar to previous releases, we will need several minor releases before we can say goodbye to 6.4, and start working on new features. Of course, certain minor features can be put in minor releases. Cerainly a Linux person can get set_proctitle working for the ps args. Massimo has done most of the work in breaking out that functionality. --------------------------------------------------------------------------- Additions --------- new functoins and test INET address type(Tom Helbekkmo, D'Arcy) CREATE TABLE test (x text, s serial) fails if no database creation permission regression test all platforms Serious Items ------------ change pg args for platforms that don't support argv changes(setproctitle()?, sendmail hack?) Docs ---- generate html/postscript documentation make sure all changes are documented properly Minor items ----------- cnf-ify still can exhaust memory, make SET KSQO more generic permissions on indexes: what do they do? should it be prevented? allow multiple generic operators in expressions without the use of parentheses document/trigger/rule so changes to pg_shadow create pg_pwd large objects orphanage improve group handling improve PRIMARY KEY handling generate postmaster pid file and remove flock/fcntl lock code add ability to specifiy location of lock/socket files -- Bruce Momjian | http://www.op.net/~candle maillist@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
> While it will be possible, I would like people to concentrate on the
> existing 6.4 issues we have, and discourage parallel development on
> separate final and features source trees.
As Bruce describes, a "quiet time" just before and up to a month after a
major release is a _really_ good idea. For a couple of reasons:
1) it lets us put out bugfix releases with a minimum of trouble
2) it lets people planning larger changes for the next release to work
on a stable, quiet tree, with some assurance that they will likely be
able to remerge their work when things unfreeze.
imho we made a few too many changes (leading to uncertainties in exactly
how much had changed, and uncertainty in how much might be newly broken)
in the v6.3->v6.3.1->v6.3.2 release series, and we should try to be even
quieter this time around.
Bruce, can you add the following items to the ToDo for docs:
> Docs
> ----
> generate html/postscript documentation
(User's Guide, Administrator's Guide, Programmer's Guide) (Thomas)
> make sure all changes are documented properly (All)
markup and merge JDBC docs from Peter (Thomas, others??)
merge the release notes into doc/src/sgml/release.sgml (Bruce, Thomas)
generate new text-format INSTALL and README from sgml sources (Thomas)
Thanks.
- Tom
> > While it will be possible, I would like people to concentrate on the > > existing 6.4 issues we have, and discourage parallel development on > > separate final and features source trees. > > As Bruce describes, a "quiet time" just before and up to a month after a > major release is a _really_ good idea. For a couple of reasons: > > 1) it lets us put out bugfix releases with a minimum of trouble > > 2) it lets people planning larger changes for the next release to work > on a stable, quiet tree, with some assurance that they will likely be > able to remerge their work when things unfreeze. > > imho we made a few too many changes (leading to uncertainties in exactly > how much had changed, and uncertainty in how much might be newly broken) > in the v6.3->v6.3.1->v6.3.2 release series, and we should try to be even > quieter this time around. Yes. > > Bruce, can you add the following items to the ToDo for docs: > > > Docs > > ---- > > generate html/postscript documentation > (User's Guide, Administrator's Guide, Programmer's Guide) (Thomas) > > make sure all changes are documented properly (All) > > markup and merge JDBC docs from Peter (Thomas, others??) > merge the release notes into doc/src/sgml/release.sgml (Bruce, Thomas) > generate new text-format INSTALL and README from sgml sources (Thomas) Added. I know I need to give you a new HISTORY file, and I will do that this weekend, hopefully. -- Bruce Momjian | http://www.op.net/~candle maillist@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
Thomas, can you check the pg_proc table, and remove any of the functions that are no longer needed. Seems we have a lot of them in there that used to do conversions, that are no longer needed. There are even functions to convert from int2 to int2. We are also running low on systgem oids. -- Bruce Momjian | http://www.op.net/~candle maillist@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
> Thomas, can you check the pg_proc table, and remove any of the
> functions that are no longer needed. Seems we have a lot of them in
> there that used to do conversions, that are no longer needed.
> There are even functions to convert from int2 to int2. We are also
> running low on systgem oids.
Is this a problem for v6.4? Perhaps we can go with what we have for now,
and do a cleanup early in v6.5 development?
One thing: I've been thinking that, although we now do "automatic
coersions" of types which will try to do the right thing by converting
expression or function arguments to the appropriate type if there is not
direct match in the catalog, a direct match is always/usually better to
have. So, for example, there is an operator defined to multiply an int2
by an int4. If one actually had an expression that was
'2'::int2 * '4'::int4
then this operator would be used. If one removed this operator, then the
expression would still be evaluated, but done as
int4('2'::int2) * '4'::int4
which in this case will give the correct result, though be marginally
slower because of the extra function call.
But in principle there may be occasions when a "mixed type" operator
will give a better/more accurate result than doing a type conversion and
then a "uniform type" operation. So we should probably plan on leaving
most of the mixed-type operators and functions in the system.
- Tom
I see it now. There is parse_coerce.h. I need to use that for the CIDR type, because it is the same as INET inside. -- Bruce Momjian | http://www.op.net/~candle maillist@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
On Thu, 22 Oct 1998, Thomas G. Lockhart wrote:
> > While it will be possible, I would like people to concentrate on the
> > existing 6.4 issues we have, and discourage parallel development on
> > separate final and features source trees.
>
> As Bruce describes, a "quiet time" just before and up to a month after a
> major release is a _really_ good idea. For a couple of reasons:
>
> 1) it lets us put out bugfix releases with a minimum of trouble
>
> 2) it lets people planning larger changes for the next release to work
> on a stable, quiet tree, with some assurance that they will likely be
> able to remerge their work when things unfreeze.
I don't agree...the problem is that our times between releases
tends to be...erratic. It was supposed to be 3+1mos, and is turning into,
what, 5+1?
Not all changes to the source tree require a dump/reload to take
effect...we have 4 patches in the ftp site right now, to v6.3.2, with the
first dated Apr21st, and the last dated Jul30th. With a STABLE vs CURRENT
branch, those patches could have been applied to the STABLE branch, and a
quick v6.3.x release could have been regress tested and released. That in
itself would have saved some of the problems where ppl had downloaded the
'newest release' but had problems because they didn't grab the patches to
go along with it.
The problem right now is we look at it as being one stream...right
now, the only thing that should be left for v6.4 is bug fixes, and there
should be no reason to hold up continued development while we wait for
each possible bug report to flow in.
With two branches, there should be no reason why a patch that
Vadim comes up with to fix a "rarely hit, but often disastrous" bug in
indexes can't be applied and tested in both tree. Then a quick v6.4.1 can
be released that those not wishing to run "latest and greatest" can run
without having to lose out on that major fix...
The idea is that with very little work on anyone's part, we can
easily provide a more stable foundation for those starting out and wishing
to use it in a production environment. Right now, we have a v6.3.2 from
April 19th, with four patches that can be applied...but how many ppl would
actually apply those patches in a production environment? Most ppl would
download and upgrade to v6.3.3 which had those patches applied...
I don't know...its something we just did with INN, cause we still
had some bugs to work out on 2.2, but some of the developers who don't
work on the areas involved are getting restless to get some work
done...gives them a chance to move forward without affecting the RELEASE
scheduale...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > Thomas, can you check the pg_proc table, and remove any of the
> > functions that are no longer needed. Seems we have a lot of them in
> > there that used to do conversions, that are no longer needed.
> > There are even functions to convert from int2 to int2. We are also
> > running low on systgem oids.
>
> Is this a problem for v6.4? Perhaps we can go with what we have for now,
> and do a cleanup early in v6.5 development?
>
> One thing: I've been thinking that, although we now do "automatic
> coersions" of types which will try to do the right thing by converting
> expression or function arguments to the appropriate type if there is not
> direct match in the catalog, a direct match is always/usually better to
> have. So, for example, there is an operator defined to multiply an int2
> by an int4. If one actually had an expression that was
>
> '2'::int2 * '4'::int4
>
> then this operator would be used. If one removed this operator, then the
> expression would still be evaluated, but done as
>
> int4('2'::int2) * '4'::int4
>
> which in this case will give the correct result, though be marginally
> slower because of the extra function call.
>
> But in principle there may be occasions when a "mixed type" operator
> will give a better/more accurate result than doing a type conversion and
> then a "uniform type" operation. So we should probably plan on leaving
> most of the mixed-type operators and functions in the system.
Yes. Leave it for 6.4. Just keep it mind next time you are looking in
there.
-- Bruce Momjian | http://www.op.net/~candle maillist@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
> I don't agree...the problem is that our times between releases > tends to be...erratic. It was supposed to be 3+1mos, and is turning into, > what, 5+1? > > Not all changes to the source tree require a dump/reload to take > effect...we have 4 patches in the ftp site right now, to v6.3.2, with the > first dated Apr21st, and the last dated Jul30th. With a STABLE vs CURRENT > branch, those patches could have been applied to the STABLE branch, and a > quick v6.3.x release could have been regress tested and released. That in > itself would have saved some of the problems where ppl had downloaded the > 'newest release' but had problems because they didn't grab the patches to > go along with it. > > The problem right now is we look at it as being one stream...right > now, the only thing that should be left for v6.4 is bug fixes, and there > should be no reason to hold up continued development while we wait for > each possible bug report to flow in. > > With two branches, there should be no reason why a patch that > Vadim comes up with to fix a "rarely hit, but often disastrous" bug in > indexes can't be applied and tested in both tree. Then a quick v6.4.1 can > be released that those not wishing to run "latest and greatest" can run > without having to lose out on that major fix... > > The idea is that with very little work on anyone's part, we can > easily provide a more stable foundation for those starting out and wishing > to use it in a production environment. Right now, we have a v6.3.2 from > April 19th, with four patches that can be applied...but how many ppl would > actually apply those patches in a production environment? Most ppl would > download and upgrade to v6.3.3 which had those patches applied... > > I don't know...its something we just did with INN, cause we still > had some bugs to work out on 2.2, but some of the developers who don't > work on the areas involved are getting restless to get some work > done...gives them a chance to move forward without affecting the RELEASE > scheduale... We have this discussion just before every release. The farther away the memory of the 1.* release mess, the less likely Marc is to agree. It will not work. It will not provide the stable released we need. But, if you want to Linux it, go ahead. -- Bruce Momjian | http://www.op.net/~candle maillist@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
Thus spake Bruce Momjian
> It will not work. It will not provide the stable released we need.
> But, if you want to Linux it, go ahead.
Way to hit Marc's hot buttons, Bruce. :-)
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
On Thu, 22 Oct 1998, Bruce Momjian wrote:
>
> We have this discussion just before every release. The farther away the
> memory of the 1.* release mess, the less likely Marc is to agree.
>
> It will not work. It will not provide the stable released we need.
> But, if you want to Linux it, go ahead.
Actually, its a BSDism, not a Linuxism...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Thu, 22 Oct 1998, D'Arcy J.M. Cain wrote:
> Thus spake Bruce Momjian
> > It will not work. It will not provide the stable released we need.
> > But, if you want to Linux it, go ahead.
>
> Way to hit Marc's hot buttons, Bruce. :-)
Naw...Bruce and I have known each other for much too long for me
to let that happen :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Thus spake The Hermit Hacker
> > Way to hit Marc's hot buttons, Bruce. :-)
>
> Naw...Bruce and I have known each other for much too long for me
> to let that happen :)
I know. I assumed that that's how he knew your hot button so well. :-)
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
On Thu, 22 Oct 1998, D'Arcy J.M. Cain wrote:
> Thus spake The Hermit Hacker
> > > Way to hit Marc's hot buttons, Bruce. :-)
> >
> > Naw...Bruce and I have known each other for much too long for me
> > to let that happen :)
>
> I know. I assumed that that's how he knew your hot button so well. :-)
Good point :)
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> I know. I assumed that that's how he knew your hot button so well. :-)
Heeeyyyyy. Waaait a minute. I thought Bruce was giving Mark a
compliment...
- Tom