Release cycle length

The time from release 7.3 to release 7.4 was 355 days, an all-time high.
We really need to shorten that. We already have a number of significant
improvements in 7.5 now, and several good ones coming up in the next few
weeks. We cannot let people wait 1 year for that. I suggest that we aim
for a 6 month cycle, consisting of approximately 4 months of development
and 2 months of cleanup. So the start of the next beta could be the 1st
of March. What do you think?

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Tue, 18 Nov 2003, Peter Eisentraut wrote:

> The time from release 7.3 to release 7.4 was 355 days, an all-time high.
> We really need to shorten that. We already have a number of significant
> improvements in 7.5 now, and several good ones coming up in the next few
> weeks. We cannot let people wait 1 year for that. I suggest that we aim
> for a 6 month cycle, consisting of approximately 4 months of development
> and 2 months of cleanup. So the start of the next beta could be the 1st
> of March. What do you think?

That is the usual goal *nod* Same goal we try for each release, and never
quite seem to get there ... we'll try 'yet again' with v7.5 though, as we
always do :)

Marc G. Fournier writes:

> That is the usual goal *nod* Same goal we try for each release, and never
> quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
> always do :)

I don't see how we could have tried for a 4-month development period and
ended up with an 8-month period. Something went *really* wrong there.
Part of that may have been that few people were actually aware of that
schedule.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Tue, 18 Nov 2003, Peter Eisentraut wrote:

> Marc G. Fournier writes:
>
> > That is the usual goal *nod* Same goal we try for each release, and never
> > quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
> > always do :)
>
> I don't see how we could have tried for a 4-month development period and
> ended up with an 8-month period. Something went *really* wrong there.
> Part of that may have been that few people were actually aware of that
> schedule.

Everyone on -hackers should have been aware of it, as its always
discussed at the end of the previous release cycle ... and I don't think
we've hit a release cycle yet that has actually stayed in the 4 month
period :( Someone is always 'just sitting on something that is almost
done' at the end that pushes it further then originally planned ...

Just did a quick search on archives, and the original plan was for a
release in mid-2003, which means the beta would have been *at least* a
month before that, so beta starting around May:

http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php

On Mon, 17 Nov 2003, Marc G. Fournier wrote:

> On Tue, 18 Nov 2003, Peter Eisentraut wrote:
>
> > Marc G. Fournier writes:
> >
> > > That is the usual goal *nod* Same goal we try for each release, and never
> > > quite seem to get there ... we'll try 'yet again' with 7.5 though, as we
> > > always do :)
> >
> > I don't see how we could have tried for a 4-month development period and
> > ended up with an 8-month period. Something went *really* wrong there.
> > Part of that may have been that few people were actually aware of that
> > schedule.
>
> Everyone on -hackers should have been aware of it, as its always
> discussed at the end of the previous release cycle ... and I don't think
> we've hit a release cycle yet that has actually stayed in the 4 month
> period :( Someone is always 'just sitting on something that is almost
> done' at the end that pushes it further then originally planned ...
>
>
>

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> The time from release 7.3 to release 7.4 was 355 days, an all-time
> high. We really need to shorten that.

Why is that?

-Neil

Marc G. Fournier writes:

> Just did a quick search on archives, and the original plan was for a
> release in mid-2003, which means the beta would have been *at least* a
> month before that, so beta starting around May:
>
> http://archives.postgresql.org/pgsql-hackers/2002-11/msg00975.php

That was a Bruce Momjian estimate mentioned in passing, not an affirmed
plan. Also, I think Bruce's estimates are notoriously off by years. ;-)

--
Peter Eisentraut peter_e(at)gmx(dot)net

Neil Conway writes:

> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > The time from release 7.3 to release 7.4 was 355 days, an all-time
> > high. We really need to shorten that.
>
> Why is that?

First, if you develop something today, the first time users would
realistically get a hand at it would be January 2005. Do you want that?
Don't you want people to use your code? We fix problems, but people must
wait a year for the fix?

Second, the longer a release cycle, the more problems amass. People just
forget what they were doing in the beginning, no one is around to fix the
problems introduced earlier, no one remembers anything when it comes time
to write release notes. The longer you develop, the more parallel efforts
are underway, and it becomes impossible to synchronize them to a release
date. People are not encouraged to provide small, well-thought-out,
modular improvements. Instead, they break everything open and worry about
it later. At the end, it's always a rush to close these holes.

Altogether, it's a loss for both developers and users.

--
Peter Eisentraut peter_e(at)gmx(dot)net

> The time from release 7.3 to release 7.4 was 355 days, an all-time high.
> We really need to shorten that. We already have a number of significant
> improvements in 7.5 now, and several good ones coming up in the next few
> weeks. We cannot let people wait 1 year for that. I suggest that we aim
> for a 6 month cycle, consisting of approximately 4 months of development
> and 2 months of cleanup. So the start of the next beta could be the 1st
> of March. What do you think?

So long as pg_dump object ordering is an early fix to make upgrades
rather more painless, I'm all for it :)

Does anyone have a comparison of how many lines of code were added in
this release compared to previous?

Chris

> Everyone on -hackers should have been aware of it, as its always
> discussed at the end of the previous release cycle ... and I don't think
> we've hit a release cycle yet that has actually stayed in the 4 month
> period :( Someone is always 'just sitting on something that is almost
> done' at the end that pushes it further then originally planned ...

I think that the core just need to be tough on it, that's all.

If we have pre-published target dates, then everyone knows if they can
get their code in or not for that date.

Chris

Hello,

Personally I am for long release cycles, at least for major releases.
In fact
as of 7.4 I think there should possibly be a slow down in releases with more
incremental releases (minor releases) throughout the year.

People are running their companies and lives off of PostgreSQL, they
should
be able to rely on a specific feature set, and support from the community
for longer.

Sincerely,

Joshua Drake

Peter Eisentraut wrote:

>Neil Conway writes:
>
>
>
>>Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>
>>
>>>The time from release 7.3 to release 7.4 was 355 days, an all-time
>>>high. We really need to shorten that.
>>>
>>>
>>Why is that?
>>
>>
>
>First, if you develop something today, the first time users would
>realistically get a hand at it would be January 2005. Do you want that?
>Don't you want people to use your code? We fix problems, but people must
>wait a year for the fix?
>
>Second, the longer a release cycle, the more problems amass. People just
>forget what they were doing in the beginning, no one is around to fix the
>problems introduced earlier, no one remembers anything when it comes time
>to write release notes. The longer you develop, the more parallel efforts
>are underway, and it becomes impossible to synchronize them to a release
>date. People are not encouraged to provide small, well-thought-out,
>modular improvements. Instead, they break everything open and worry about
>it later. At the end, it's always a rush to close these holes.
>
>Altogether, it's a loss for both developers and users.
>
>
>

--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-222-2783 - jd(at)commandprompt(dot)com - http://www.commandprompt.com
Editor-N-Chief - PostgreSQl.Org - http://www.postgresql.org

On Tue, 18 Nov 2003, Christopher Kings-Lynne wrote:

> > Everyone on -hackers should have been aware of it, as its always
> > discussed at the end of the previous release cycle ... and I don't think
> > we've hit a release cycle yet that has actually stayed in the 4 month
> > period :( Someone is always 'just sitting on something that is almost
> > done' at the end that pushes it further then originally planned ...
>
> I think that the core just need to be tough on it, that's all.
>
> If we have pre-published target dates, then everyone knows if they can
> get their code in or not for that date.

Right now, I believe we are looking at an April 1st beta, and a May 1st
related ... those are, as always, *tentative* dates that will become more
fine-tuned as those dates become nearer ...

April 1st, or 4 mos from last release, tends to be what we aim for with
all releases ... as everyone knows, we don't necessarily acheive it, but
...

Actually, historically, it looks like we've always been close to 12 months
between releases ... 7.0->7.1: ~11mos, 7.1->7.2: ~10mos, 7.2->7.3: ~9 mos,
and 7.3->7.4: ~12mos ... so, on average, we're dealing with an ~10mos
release cycle for the past 3 years ...

svr1# ls -l */postgresql-7.?.tar.gz
-rw-rw-r-- 1 pgsql pgsql 9173732 May 9 2000 v7.0/postgresql-7.0.tar.gz
-rw-r--r-- 1 pgsql pgsql 8088678 Apr 13 2001 v7.1/postgresql-7.1.tar.gz
-rw-r--r-- 1 pgsql pgsql 9180168 Feb 4 2002 v7.2/postgresql-7.2.tar.gz
-rw-r--r-- 1 pgsql pgsql 11059455 Nov 27 2002 v7.3/postgresql-7.3.tar.gz
-rw-r--r-- 1 pgsql pgsql 12311256 Nov 16 17:57 v7.4/postgresql-7.4.tar.gz

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:

> Hello,
>
> Personally I am for long release cycles, at least for major releases.
> In fact
> as of 7.4 I think there should possibly be a slow down in releases with more
> incremental releases (minor releases) throughout the year.

That would pretty much mean changing the "minor releases only for
serious bugfixes" philosphy. Is that what you are advocating?

> People are running their companies and lives off of PostgreSQL,
> they should be able to rely on a specific feature set, and support
> from the community for longer.

If 7.3.4 works for you, there's nothing to stop you running it until
the end of time... If you can't patch in bugfixes yourself, you
should be willing to pay for support. Commercial companies like Red
Hat don't support their releases indefinitely for free; why should the
PG community be obligated to?

Also, we very rarely remove features--AUTOCOMMIT on the server is
about the only one I can think of.

-Doug

> Right now, I believe we are looking at an April 1st beta, and a May 1st
> related ... those are, as always, *tentative* dates that will become more
> fine-tuned as those dates become nearer ...
>
> April 1st, or 4 mos from last release, tends to be what we aim for with
> all releases ... as everyone knows, we don't necessarily acheive it, but

Make it April 2nd, otherwise everyone will think it's a joke :P

Chris

Marc G. Fournier writes:

> Right now, I believe we are looking at an April 1st beta, and a May 1st
> related ... those are, as always, *tentative* dates that will become more
> fine-tuned as those dates become nearer ...

OK, here start the problems. Development already started, so April 1st is
already 5 months development. Add 1 month because no one is willing to
hold people to these dates. So that's 6 months. Then for 6 months of
development, you need at least 2 months of beta. So we're already in the
middle of July, everyone is on vacation, and we'll easily reach the 9
months -- instead of 6.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> First, if you develop something today, the first time users would
> realistically get a hand at it would be January 2005. Do you want
> that? Don't you want people to use your code?

Sure :-) But I don't mind a long release cycle if it is better for
users.

> We fix problems, but people must wait a year for the fix?

A couple points:

(a) Critical problems can of course be fixed via point releases in
the current stable release series

(b) As PostgreSQL gets more mature, the number of absolutely show
stopping features or bug fixes in a new release gets
smaller. For example, I'd argue that neither 7.3 or 7.4 include
a single feature that is as important as 7.2's lazy VACUUM or
7.1's WAL. There are lots of great features, but the set of
absolutely essential new features tends to grow smaller over
time. I'd wager that for the vast majority of our user base,
PostgreSQL already works well.

(c) As PostgreSQL gets more mature, putting out stable,
production-worthy releases becomes even more important. In
theory, longer release cycles contribute to higher quality
releases: we have more time to implement new features properly,
polish rough edges and document things, test and find bugs, and
ensure that features we've implemented earlier in the release
cycle are properly thought out, and so forth.

Note that whether or not we are using those 355 days effectively
is another story -- it may well be true that there are we could
make parts of the development process much more efficient.

Furthermore, longer release cycles reduce, to some degree, the pain of
upgrades. Unless we make substantial improvements to the upgrade story
any time soon, I wouldn't be surprised if many DBAs are relieved at
only needing to upgrade once a year.

> The longer you develop, the more parallel efforts are underway, and
> it becomes impossible to synchronize them to a release date.

I think this is inherent to the way PostgreSQL is developed: Tom has
previously compared PostgreSQL release scheduling to herding cats :-)
As long as much of the work on the project is done by volunteers in
their spare time, ISTM that coordinating everyone toward a single
release date is going to be difficult, if not impossible. The length
of the release cycle doesn't really effect this, IMHO.

> People are not encouraged to provide small, well-thought-out,
> modular improvements.

I agree we can always do better when it comes to code quality. I think
the NetBSD team puts it well:

Some systems seem to have the philosophy of "If it works, it's
right". In that light NetBSD could be described as "It doesn't
work /unless/ it's right".

That said, I don't see how this is related to the release schedule. In
fact, one could argue that a longer release schedule gives new
features a longer "gestation period" during which developers can
ensure that they are well-thought out and implemented properly.

> Altogether, it's a loss for both developers and users.

I don't think it's nearly as clear-cut as that. Both types of release
scheduling have their benefits and their drawbacks. My main point is
really that a short release cycle is not an unqualified good (not to
mention that in the past we've been completely unable to actually
*execute* a short release cycle, making this whole discussion a little
academic).

-Neil

Peter Eisentraut wrote:

>Marc G. Fournier writes:
>
>
>>Right now, I believe we are looking at an April 1st beta, and a May 1st
>>related ... those are, as always, *tentative* dates that will become more
>>fine-tuned as those dates become nearer ...
>>
>>
>
>OK, here start the problems. Development already started, so April 1st is
>already 5 months development. Add 1 month because no one is willing to
>hold people to these dates. So that's 6 months. Then for 6 months of
>development, you need at least 2 months of beta. So we're already in the
>middle of July, everyone is on vacation, and we'll easily reach the 9
>months -- instead of 6.
>
>
Do you think that 2 months for beta is realistic? Tom announced feature
freeze on July 1.
http://archives.postgresql.org/pgsql-hackers/2003-07/msg00040.php

So 7.4 took about 4.5 months to get from feature freeze to release. I
think feature freeze is the important date that developers of new
features need to concern themselves with.

I agree with Peter's other comment, that the longer the development
cycle, the longer the beta / bug shakeout period, perhaps a shorter dev
cycle would yield a shorter beta period, but perhaps it would also
result in a less solid release.

On Tue, 18 Nov 2003, Peter Eisentraut wrote:

> Marc G. Fournier writes:
>
> > Right now, I believe we are looking at an April 1st beta, and a May 1st
> > related ... those are, as always, *tentative* dates that will become more
> > fine-tuned as those dates become nearer ...
>
> OK, here start the problems. Development already started, so April 1st is
> already 5 months development. Add 1 month because no one is willing to
> hold people to these dates. So that's 6 months. Then for 6 months of
> development, you need at least 2 months of beta. So we're already in the
> middle of July, everyone is on vacation, and we'll easily reach the 9
> months -- instead of 6.

'K, Sept 1st it is then ... sounds reasonable to me :)

"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> So 7.4 took about 4.5 months to get from feature freeze to release.
> I think feature freeze is the important date that developers of new
> features need to concern themselves with.

Rather than the length of the release cycle, I think it's the length
of the beta cycle that we should focus on improving. IMHO, we should
try to make the beta process more efficient: sometimes I get the
impression that the beta process just drags on and on, without the
extra time resulting in a huge improvement in the reliability of the
.0 release (witness the fact that all the .0 releases I can remember
have had a *lot* of serious bugs in them -- we can't catch everything
of course, but I think there is definitely room for improvement).

That said, I'm not really sure how we can make better use of the beta
period. One obvious improvement would be making the beta announcements
more visible: the obscurity of the beta process on www.postgresql.org
for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
what we can do to produce a more reliable .0 release in less time?

-Neil

Neil Conway wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > First, if you develop something today, the first time users would
> > realistically get a hand at it would be January 2005. Do you want
> > that? Don't you want people to use your code?
>
> Sure :-) But I don't mind a long release cycle if it is better for
> users.

Given that users can run whatever they like, it's not clear that a long
release cycle is better for users.

> (c) As PostgreSQL gets more mature, putting out stable,
> production-worthy releases becomes even more important. In
> theory, longer release cycles contribute to higher quality
> releases: we have more time to implement new features properly,
> polish rough edges and document things, test and find bugs, and
> ensure that features we've implemented earlier in the release
> cycle are properly thought out, and so forth.

On the other hand, the longer you wait to release a new feature, the
longer it will be before you get your REAL testing done. You don't want
to release something that hasn't at least been looked over and checked
out by the development community first, of course, but waiting beyond that
point to release a new version of PG doesn't help you that much, because
most people aren't going to run the latest CVS version -- they'll run
the latest released version, whatever that may be. So the time between
the testing phase for the feature you implement and the version release
is essentially "dead time" for testing of that feature, because most
developers have moved on to working on and/or testing something else.

That's why the release methodology used by the Linux kernel development
team is a reasonable one. Because the development releases are still
releases, people who wish to be more on the bleeding edge can do so
without having to grab the source from CVS and compile it themselves.
And package maintainers are more likely to package up the development
version if it's given to them in a nice, prepackaged format, even if
it's just a source tarball.

> Note that whether or not we are using those 355 days effectively
> is another story -- it may well be true that there are we could
> make parts of the development process much more efficient.
>
> Furthermore, longer release cycles reduce, to some degree, the pain of
> upgrades. Unless we make substantial improvements to the upgrade story
> any time soon, I wouldn't be surprised if many DBAs are relieved at
> only needing to upgrade once a year.

But DBAs only "need" to upgrade as often as they feel like. Any
reasonable distribution will give them an option of using either the
stable version or the development version anyway, if we're talking about
prepackaged versions.

> > The longer you develop, the more parallel efforts are underway, and
> > it becomes impossible to synchronize them to a release date.
>
> I think this is inherent to the way PostgreSQL is developed: Tom has
> previously compared PostgreSQL release scheduling to herding cats :-)
> As long as much of the work on the project is done by volunteers in
> their spare time, ISTM that coordinating everyone toward a single
> release date is going to be difficult, if not impossible. The length
> of the release cycle doesn't really effect this, IMHO.

Linux, too, is done largely by volunteers in their spare time. Yet
Linux kernel releases are much more frequent than PostgreSQL releases.
One difference is that the Linux community makes a distinction between
development releases and stable releases. The amount of time between
stable releases is probably about the same as it is for PostgreSQL. The
difference is that the *only* releases PostgreSQL makes are stable
releases (or release candidates, when a stable release is close).
That's something we might want to re-think.

--
Kevin Brown kevin(at)sysexperts(dot)com

Matthew T. O'Connor wrote:
> I agree with Peter's other comment, that the longer the development
> cycle, the longer the beta / bug shakeout period, perhaps a shorter dev
> cycle would yield a shorter beta period, but perhaps it would also
> result in a less solid release.

Perhaps. Perhaps not. The fewer the changes, the less complexity you
have to manage.

But it would certainly result in a smaller set of feature changes per
release. Some people might regard that as a good thing.

The advantage to doing more frequent releases is that new features end
up with more real-world testing within a given block of time, on
average, because a lot more people pick up the releases than the CVS
snapshots or even release candidates..

--
Kevin Brown kevin(at)sysexperts(dot)com

> That said, I'm not really sure how we can make better use of the beta
> period. One obvious improvement would be making the beta announcements
> more visible: the obscurity of the beta process on www.postgresql.org
> for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
> what we can do to produce a more reliable .0 release in less time?

I can think of a few things.

1. Try to encourage list members to actually test stuff. For example, I
decided to find stuff that might be broken. So I checked the tutorial
scripts (no-one ever looks at them) and found heaps of bugs. I thought
about some new features and tried to break them. I also tend to find
bugs by coding phpPgAdmin and delving into the nitty gritty of stuff.

Maybe we could actually ask for people for the 'beta team'. Then, once
we have volunteers, they are each assigned a set of features to test by
the 'testing co-ordinator' (a new core position, say?) What you are
asked to test depends on your skill, say.

eg. Someone who just knows how to use postgres could test my upcoming
COMMENT ON patch. (It's best if I myself do not test it) Someone with
more skill with a debugger can be asked to test unique hash indexes by
playing with concurrency, etc.

The test co-ordinator could also manage the testing of new features as
they are committed to save time later.

The co-ordinator should also maintain a list of what features have been
committed, which have been code reviewed (what Tom usually does) and
which have been tested.

Of course, I'm not talking about exhaustive testing here, just better
and more organised that what we currently have.

Chris

Neil Conway writes:

> That said, I'm not really sure how we can make better use of the beta
> period. One obvious improvement would be making the beta announcements
> more visible: the obscurity of the beta process on www.postgresql.org
> for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
> what we can do to produce a more reliable .0 release in less time?

Here are a couple of ideas:

0. As you say, make it known to the public. Have people test their
in-development applications using a beta.

1. Start platform testing on day 1 of beta. Last minute fixes for AIX or
UnixWare are really becoming old jokes.

2. Have a complete account of the changes available at the start of beta,
so people know what to test.

3. Use a bug-tracking system so that "open items" are known early and by
everyone.

4. Have a schedule. Not "We're looking at a release early in the later
part of this year.", but dates for steps such as feature freeze then,
proposals for open issues fielded then, string freeze then,
release candiate then.

5. If need be, have a release management team that manages 0-4.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Mon, 17 Nov 2003, Neil Conway wrote:

> That said, I'm not really sure how we can make better use of the beta
> period. One obvious improvement would be making the beta announcements
> more visible: the obscurity of the beta process on www.postgresql.org
> for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
> what we can do to produce a more reliable .0 release in less time?

Agreed ... here's a thought ...

take the download page and break it into two pages:

page 1: broken down into "dev" vs "stable" versions, including the date of
release ...

page 2: when you click on the version you want to download, it brings you
to a subpage that is what the main page currently is (with all the flags
and such) but instead of just sending ppl to the ftp site itself, actually
have the link go to the directory that contains that version on the mirror
site ...

that first page of the download could contain descriptoins of the variosu
releases, and state of releases?

> eg. Someone who just knows how to use postgres could test my upcoming
> COMMENT ON patch. (It's best if I myself do not test it) Someone with
> more skill with a debugger can be asked to test unique hash indexes by
> playing with concurrency, etc.

I forgot to mention that people who just have large, complex production
databases and test servers at their disposal should be given the task of:

1. Dumping their old version database
2. Loading that into the dev version of postgres
3. Dumping that using dev pg_dump
4. Loading that dump back in
5. Dumping it again
6. Diffing 3 and 5

Chris

--On Tuesday, November 18, 2003 04:43:12 +0100 Peter Eisentraut
<peter_e(at)gmx(dot)net> wrote:

> Neil Conway writes:
>
>> That said, I'm not really sure how we can make better use of the beta
>> period. One obvious improvement would be making the beta announcements
>> more visible: the obscurity of the beta process on www.postgresql.org
>> for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
>> what we can do to produce a more reliable .0 release in less time?
>
> Here are a couple of ideas:
>
> 0. As you say, make it known to the public. Have people test their
> in-development applications using a beta.
>
> 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or
> UnixWare are really becoming old jokes.
The only reason we had last minute stuff for UnixWare this time was the
timing of PG's release and the UP3 release from SCO.

I try to test stuff fairly frequently, and this time I didn't know when,
exactly, SCO would make the release of the updated compiler.

LER

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Tue, 18 Nov 2003, Peter Eisentraut wrote:

> 0. As you say, make it known to the public. Have people test their
> in-development applications using a beta.

and how do you propose we do that? I think this is the hard part ...
other then the first beta, I post a note out to -announce and -general
that the beta's have been tag'd and bundled for download ... I know Sean
does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb
maintainers do anything until the final release ...

> 1. Start platform testing on day 1 of beta. Last minute fixes for AIX
> or UnixWare are really becoming old jokes.

then each beta will have to be "re-certified" for that beta, up until
release ... doable, but I don't think you'll find many that will bother
until we are close to release ...

> 2. Have a complete account of the changes available at the start of beta,
> so people know what to test.

Bruce, when do you do your initial HISTORY file? Something to move to the
start of beta, if not?

> 3. Use a bug-tracking system so that "open items" are known early and by
> everyone.

Waiting to see anyone decide on which one to use ... willing to spend the
time working to get it online ...

> 4. Have a schedule. Not "We're looking at a release early in the later
> part of this year.", but dates for steps such as feature freeze then,
> proposals for open issues fielded then, string freeze then,
> release candiate then.

We try that every release ...

> 5. If need be, have a release management team that manages 0-4.

Core does that, but we just don't feel that being totally rigid is (or has
ever been) a requirement ... but, if you can provide suggestions on points
0 and 3, we're all ears ...

On Mon, 17 Nov 2003, Larry Rosenman wrote:

>
> I try to test stuff fairly frequently, and this time I didn't know when,
> exactly, SCO would make the release of the updated compiler.

And there was no way you could predict that your contact there would take
off on holidays either :(

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Tue, 18 Nov 2003, Peter Eisentraut wrote:
>
>> 0. As you say, make it known to the public. Have people test their
>> in-development applications using a beta.
>
> and how do you propose we do that? I think this is the hard part

(1) Make the beta more obvious on the website, as we've already
discussed

(2) Make a freshmeat.net release announcement for _each_ beta, RC, and
of course the final release (we totally missed this during 7.4).
There are probably other software release announcement sites we
could inform.

(3) Is it worth trying to get some technical press coverage for the
start of the beta process? I don't mean on PHB-oriented sites like
ComputerWorld or ZdNet where we need to do the work of getting a
press release prepared, but OSNews or Slashdot just need a link to
the release notes and the source tarballs.

Any other suggestions?

Perhaps we could add a list of this sort to src/tools/RELEASE_CHANGES?

-Neil

On Tue, 18 Nov 2003, Neil Conway wrote:

> "Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> > On Tue, 18 Nov 2003, Peter Eisentraut wrote:
> >
> >> 0. As you say, make it known to the public. Have people test their
> >> in-development applications using a beta.
> >
> > and how do you propose we do that? I think this is the hard part
>
> (1) Make the beta more obvious on the website, as we've already
> discussed
>
> (2) Make a freshmeat.net release announcement for _each_ beta, RC, and
> of course the final release (we totally missed this during 7.4).
> There are probably other software release announcement sites we
> could inform.

Damn, I keep forgetting freshmeat.net altogether ... will get that one
during the day tomorrow ...

> (3) Is it worth trying to get some technical press coverage for the
> start of the beta process? I don't mean on PHB-oriented sites like
> ComputerWorld or ZdNet where we need to do the work of getting a
> press release prepared, but OSNews or Slashdot just need a link to
> the release notes and the source tarballs.

I think so ... just a heads up to tell ppl that we are heading into the
final stretch for the next release, and testing would be 'a good thing'
...

On Tue, Nov 18, 2003 at 12:36:11AM -0400, Marc G. Fournier wrote:
> On Tue, 18 Nov 2003, Peter Eisentraut wrote:
>
> > 0. As you say, make it known to the public. Have people test their
> > in-development applications using a beta.
>
> and how do you propose we do that? I think this is the hard part ...
> other then the first beta, I post a note out to -announce and -general
> that the beta's have been tag'd and bundled for download ... I know Sean
> does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb
> maintainers do anything until the final release ...
>

For what it is worth, I try to promote the beta testing on general bits.
I also invite people to write articles for me. To highlight a feature
or concept or just to egg people on in a short article by a guest to
general bits is very appropriate. My audience might not be core
hackers, but getting the larger user group to participate as well
as prepare for conversion is something I can help promote.
(Just contact me to submit articles for publication--the invitation
is always open.)

--elein

=============================================================
elein(at)varlena(dot)com Varlena, LLC www.varlena.com

PostgreSQL Consulting, Support & Training

PostgreSQL General Bits http://www.varlena.com/GeneralBits/
=============================================================
I have always depended on the [QA] of strangers.

----- Original-Nachricht -----
Von: "Marc G. Fournier" <scrappy(at)postgresql(dot)org>
An: Neil Conway <neilc(at)samurai(dot)com>
CC: pgsql-www(at)postgresql(dot)org, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Datum: Tuesday, November 18, 2003 05:06 AM
Betreff: [pgsql-www] [HACKERS] Release cycle length

> On Mon, 17 Nov 2003, Neil Conway wrote:
>
> > That said, I'm not really sure how we can make better use of the beta
> > period. One obvious improvement would be making the beta announcements
> > more visible: the obscurity of the beta process on www.postgresql.org
> > for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
> > what we can do to produce a more reliable .0 release in less time?
>
> Agreed ... here's a thought ...
>
> take the download page and break it into two pages:
>
> page 1: broken down into "dev" vs "stable" versions, including the date of
> release ...
>
> page 2: when you click on the version you want to download, it brings you
> to a subpage that is what the main page currently is (with all the flags
> and such) but instead of just sending ppl to the ftp site itself, actually
> have the link go to the directory that contains that version on the mirror
> site ...
>
> that first page of the download could contain descriptoins of the variosu
> releases, and state of releases?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

We could also use some download page similar to the one on httpd.apache.org - first you select a mirror (and one near you has been preselected) and under it you get a list of possible downloads... might be easier for the users than browsing through FTP...

Mit freundlichen Grüßen
Andreas Grabmüller

--
LetzPlay.de
| Freemail: http://www.letzplay.de/mail
| Forenhosting: http://www.letzplay.de/foren
>From pgsql-www-owner(at)postgresql(dot)org Tue Nov 18 04:15:07 2003
X-Original-To: pgsql-www-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (unknown [200.46.204.2])
by svr1.postgresql.org (Postfix) with ESMTP
id 8D17AD1B8BF; Tue, 18 Nov 2003 08:15:06 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
with ESMTP id 75952-08; Tue, 18 Nov 2003 04:14:37 -0400 (AST)
Received: from salem.vale-housing.co.uk (mailgate.vale-housing.co.uk [80.176.1.146])
by svr1.postgresql.org (Postfix) with ESMTP
id 680B3D1B4EF; Tue, 18 Nov 2003 04:14:31 -0400 (AST)
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: Re: Page contents
Date: Tue, 18 Nov 2003 08:14:27 -0000
Message-ID: <03AF4E498C591348A42FC93DEA9661B871FFFB(at)mail(dot)vale-housing(dot)co(dot)uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [pgsql-www] Page contents
thread-index: AcOtbgM9SAgrXxi+Rp+lkoa8ImZAFwAPSIfA
From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Justin Clift" <justin(at)postgresql(dot)org>,
<pgsql-www(at)postgresql(dot)org>,
"Marc G. Fournier" <scrappy(at)postgresql(dot)org>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200311/310
X-Sequence-Number: 2957

=20

> -----Original Message-----
> From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]=20
> Sent: 18 November 2003 00:51
> To: Dave Page
> Cc: Justin Clift; pgsql-www(at)postgresql(dot)org; Marc G. Fournier
> Subject: Re: [pgsql-www] Page contents
>=20
> Dave Page wrote:
> >=20=20
> >=20
> > > -----Original Message-----
> > > From: Bruce Momjian [mailto:pgman(at)candle(dot)pha(dot)pa(dot)us]
> > > Sent: 17 November 2003 00:34
> > > To: Dave Page
> > > Cc: Justin Clift; pgsql-www(at)postgresql(dot)org; Marc G. Fournier
> > > Subject: Re: [pgsql-www] Page contents
> > >=20
> > > Should opening an email every give you a virus? I don't think so.
> > >=20
> >=20
> > No, but my point is without proper protection/procedures a=20
> user of any=20
> > OS/MUA can open and execute a trojan.
>=20
> Right, but I think my MUA and helper applications are=20
> designed to be safe so I can't botch it up.

As have been the last few versions of Outlook (proper, dunno about
Express). To get round that protection you have to do some non-trivial
registry hacking and even then you still get warnings when you try to
open things.

Whilst there are undoubtedly vulnerabilities in Outlook, as most other
apps, I think it's unfair to blame a product just because it has a
better class of idiot in it's userbase - especially when it's their
actions that cause 99.9% of the problems.

Anyhoo, this is waaaaay off-topic for here. I'm not overly interested,
but if anyone feels compelled to keep discussing this, feel free to
email me off-list :-)

Regards, Dave.

On Tue, 2003-11-18 at 04:36, Marc G. Fournier wrote:
> On Tue, 18 Nov 2003, Peter Eisentraut wrote:
>
> > 0. As you say, make it known to the public. Have people test their
> > in-development applications using a beta.
>
> and how do you propose we do that? I think this is the hard part ...
> other then the first beta, I post a note out to -announce and -general
> that the beta's have been tag'd and bundled for download ... I know Sean
> does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb
> maintainers do anything until the final release ...

I do in fact build debs of the beta and rc releases. These have gone
into the experimental archive in Debian and are announced on Debian
lists. I even posted an announcement to pgsql-general, on 10th October
for example.

--
Oliver Elphick Oliver(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"A Song for the sabbath day. It is a good thing to
give thanks unto the LORD, and to sing praises unto
thy name, O most High." Psalms 92:1

> > 0. As you say, make it known to the public. Have people test
> > their in-development applications using a beta.
>
> and how do you propose we do that? I think this is the hard part
> ... other then the first beta, I post a note out to -announce and
> -general that the beta's have been tag'd and bundled for download
> ... I know Sean does up a 'devel' port for FreeBSD, but I don't
> believe any of the RPM/deb maintainers do anything until the final
> release ...

Incidentally, the reason that I created the -devel port is because I
needed some of the features now and didn't want to wait for a release.
As things stand, I'm getting roughly 50-100 downloads a day of my
-devel snapshots, which leads me to believe that there is some
interest in having the release engineering team push features out the
door more quickly. My eye on the pgsql repo isn't perfect, but I know
I'm not the only one using it in production.

> > 5. If need be, have a release management team that manages 0-4.
>
> Core does that, but we just don't feel that being totally rigid is
> (or has ever been) a requirement ... but, if you can provide
> suggestions on points 0 and 3, we're all ears ...

You've got FreeBSD blood in you, you know that core(at)pgsql is the same
as trb(at)FreeBSD + core(at)FreeBSD + re(at)FreeBSD + qa(at)FreeBSD(dot) I think that
core(at)pgsql's big reason for wanting to have long release cycles is to
minimize the time that pgsql developers spend with their re@ and qa@
hats on. Truth be told, pgsql's code quality in the tree is so high
that a snapshot of HEAD is almost as good as a release... the
difference being the amount of attention spent on detail, docs,
finishing touches/polish. For the # of lines of code that go into
pgsql, it's nearly bug free over 95% of the time which means to me
with an releng hat on, that pgsql could stand to increase the rate of
releases so long as the developers can stomach doing the extra merges
from HEAD to the stable branch for feature additions or possibly
watching micro version numbers increment faster than they have
historically.

For all intents and purposes, pgsql's releases are stellar and the Pg
team makes every release very important to most everyone, where
important is defined as containing features useful for everyone: as
opposed to a re@ release often model where releases don't necessarily
useful features to a majority and just lead to upgrade thrashing which
is costly to organizations. Food for thought... nothing conclusive
here. -sc

--
Sean Chittenden

On Tuesday, November 18, 2003, at 05:13 PM, Andreas Grabmüller wrote:

> ----- Original-Nachricht -----
> Von: "Marc G. Fournier" <scrappy(at)postgresql(dot)org>
> An: Neil Conway <neilc(at)samurai(dot)com>
> CC: pgsql-www(at)postgresql(dot)org, PostgreSQL Development
> <pgsql-hackers(at)postgresql(dot)org>
> Datum: Tuesday, November 18, 2003 05:06 AM
> Betreff: [pgsql-www] [HACKERS] Release cycle length
>
>> On Mon, 17 Nov 2003, Neil Conway wrote:
>>
>>> That said, I'm not really sure how we can make better use of the beta
>>> period. One obvious improvement would be making the beta
>>> announcements
>>> more visible: the obscurity of the beta process on www.postgresql.org
>>> for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
>>> what we can do to produce a more reliable .0 release in less time?
>>
>> Agreed ... here's a thought ...
>>
>> take the download page and break it into two pages:
>>
>> page 1: broken down into "dev" vs "stable" versions, including the
>> date of
>> release ...
>>
>> page 2: when you click on the version you want to download, it brings
>> you
>> to a subpage that is what the main page currently is (with all the
>> flags
>> and such) but instead of just sending ppl to the ftp site itself,
>> actually
>> have the link go to the directory that contains that version on the
>> mirror
>> site ...
>>
>> that first page of the download could contain descriptoins of the
>> variosu
>> releases, and state of releases?
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 4: Don't 'kill -9' the postmaster
>
> We could also use some download page similar to the one on
> httpd.apache.org - first you select a mirror (and one near you has
> been preselected) and under it you get a list of possible downloads...
> might be easier for the users than browsing through FTP...

From a users' standpoint, do you think the users are looking for a
mirror or for software? Maybe put the download first, then a selection
of mirrors. I haven't done a lot of downloading, so my perspective
might be a little off. And advantage of the mirror > download order
would be if people are downloading more than one item at a time. Then
they wouldn't have to go back to choose another download. However, once
they choose the mirror (and commence the download) a page could come up
offering the option to download more from this mirror.

Just some thoughts.
Michael

On Mon, Nov 17, 2003 at 20:08:41 -0500,
Neil Conway <neilc(at)samurai(dot)com> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > The time from release 7.3 to release 7.4 was 355 days, an all-time
> > high. We really need to shorten that.
>
> Why is that?

End users will find it useful.

I started using 7.4 from CVS early on because check constraints for domains
were available.

With a long release cycle you have to wait a long time to get any of
the features in a release when some of them may have been developed
early in the release cycle.

----- Original-Nachricht -----
Von: "Michael Glaesemann" <grzm(at)myrealbox(dot)com>
An: <webmaster(at)letzplay(dot)de>
CC: neilc(at)samurai(dot)com, scrappy(at)postgresql(dot)org, pgsql-www(at)postgresql(dot)org
Datum: Tuesday, November 18, 2003 01:32 PM
Betreff: [pgsql-www] [HACKERS] Release cycle length

> On Tuesday, November 18, 2003, at 05:13 PM, Andreas Grabmüller wrote:
>
> > ----- Original-Nachricht -----
> > Von: "Marc G. Fournier" <scrappy(at)postgresql(dot)org>
> > An: Neil Conway <neilc(at)samurai(dot)com>
> > CC: pgsql-www(at)postgresql(dot)org, PostgreSQL Development
> > <pgsql-hackers(at)postgresql(dot)org>
> > Datum: Tuesday, November 18, 2003 05:06 AM
> > Betreff: [pgsql-www] [HACKERS] Release cycle length
> >
> >> On Mon, 17 Nov 2003, Neil Conway wrote:
> >>
> >>> That said, I'm not really sure how we can make better use of the beta
> >>> period. One obvious improvement would be making the beta
> >>> announcements
> >>> more visible: the obscurity of the beta process on www.postgresql.org
> >>> for 7.4 was pretty ridiculous. Does anyone else have a suggestion on
> >>> what we can do to produce a more reliable .0 release in less time?
> >>
> >> Agreed ... here's a thought ...
> >>
> >> take the download page and break it into two pages:
> >>
> >> page 1: broken down into "dev" vs "stable" versions, including the
> >> date of
> >> release ...
> >>
> >> page 2: when you click on the version you want to download, it brings
> >> you
> >> to a subpage that is what the main page currently is (with all the
> >> flags
> >> and such) but instead of just sending ppl to the ftp site itself,
> >> actually
> >> have the link go to the directory that contains that version on the
> >> mirror
> >> site ...
> >>
> >> that first page of the download could contain descriptoins of the
> >> variosu
> >> releases, and state of releases?
> >>
> >> ---------------------------(end of
> >> broadcast)---------------------------
> >> TIP 4: Don't 'kill -9' the postmaster
> >
> > We could also use some download page similar to the one on
> > httpd.apache.org - first you select a mirror (and one near you has
> > been preselected) and under it you get a list of possible downloads...
> > might be easier for the users than browsing through FTP...
>
> From a users' standpoint, do you think the users are looking for a
> mirror or for software? Maybe put the download first, then a selection
> of mirrors. I haven't done a lot of downloading, so my perspective
> might be a little off. And advantage of the mirror > download order
> would be if people are downloading more than one item at a time. Then
> they wouldn't have to go back to choose another download. However, once
> they choose the mirror (and commence the download) a page could come up
> offering the option to download more from this mirror.
>
> Just some thoughts.
> Michael

Have you looked at the apache download site? I think it's goot (of course, we can put the mirror chooser under the download links - it doesn't matter for the functionality as always a different (random?) server gets preselected automatically...

Mit freundlichen Grüßen
Andreas Grabmüller

--
LetzPlay.de
| Freemail: http://www.letzplay.de/mail
| Forenhosting: http://www.letzplay.de/foren
>From pgsql-www-owner(at)postgresql(dot)org Tue Nov 18 09:48:16 2003
X-Original-To: pgsql-www-postgresql(dot)org(at)localhost(dot)postgresql(dot)org
Received: from localhost (unknown [200.46.204.2])
by svr1.postgresql.org (Postfix) with ESMTP
id 7545FD1C976; Tue, 18 Nov 2003 13:48:14 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
with ESMTP id 33296-10; Tue, 18 Nov 2003 09:47:46 -0400 (AST)
Received: from smtp-send.myrealbox.com (smtp-send.myrealbox.com [192.108.102.143])
by svr1.postgresql.org (Postfix) with ESMTP
id 5F32BD1D7D2; Tue, 18 Nov 2003 09:47:42 -0400 (AST)
Received: from myrealbox.com glaesema(at)smtp-send(dot)myrealbox(dot)com [61.115.206.98]
by smtp-send.myrealbox.com with NetMail SMTP Agent $Revision: 3.44 $ on Novell NetWare;
Tue, 18 Nov 2003 06:47:27 -0700
Date: Tue, 18 Nov 2003 22:47:24 +0900
Subject: Re: [HACKERS] Release cycle length
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
Cc: neilc(at)samurai(dot)com, scrappy(at)postgresql(dot)org,
pgsql-www(at)postgresql(dot)org
To: <webmaster(at)letzplay(dot)de>
From: Michael Glaesemann <grzm(at)myrealbox(dot)com>
In-Reply-To: <20031118133201(dot)31503(dot)qmail(at)osiris(dot)gamecrashnet(dot)de>
Message-Id: <BD8F60C3-19CD-11D8-A78A-0005029FC1A7(at)myrealbox(dot)com>
Content-Transfer-Encoding: quoted-printable
X-Mailer: Apple Mail (2.552)
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Archive-Number: 200311/313
X-Sequence-Number: 2960

On Tuesday, November 18, 2003, at 10:32 PM, Andreas Grabm=FCller wrote:
> Have you looked at the apache download site? I think it's goot (of=20
> course, we can put the mirror chooser under the download links - it=20
> doesn't matter for the functionality as always a different (random?)=20
> server gets preselected automatically...

Yes, I did. I thought it was pretty good. Nice and clean. And I like=20
how it chooses a server. I don't know how it selects. You could do it=20
by location (nearness to the client ip), server load (weight those with=20
lower server load). I'm sure there are other ways as well.

I have seen examples where you choose the download, then the server. I=20
wish I can think of one right now...

Michael

...
>
> Does anyone have a comparison of how many lines of code were added in
> this release compared to previous?
>
7.2.4: 456204 lines of code in 1021 files
7.3.4: 480491 lines of code in 1012 files
7.4: 554567 lines of code in 1128 files (boah!)

I used a fresh extracted source-directory and executed 'find postgresql-7.xxx
-name '*.c' - o -name '*.h'|wc -l' and 'find postgresql-7.xxx -name '*.c' - o
-name '*.h'|xargs cat|wc -l'

Tommi

> Chris
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

--
Dr. Eckhardt + Partner GmbH
http://www.epgmbh.de

On Tue, Nov 18, 2003 at 02:33:41PM +0100, Tommi Maekitalo wrote:
> ...
> >
> > Does anyone have a comparison of how many lines of code were added in
> > this release compared to previous?
> >
> 7.2.4: 456204 lines of code in 1021 files
> 7.3.4: 480491 lines of code in 1012 files
> 7.4: 554567 lines of code in 1128 files (boah!)

I used SLOCcount by David A. Wheeler at some point on various releases
(including 7.1.3 IIRC) and at some point the number of lines actually
_decreased_. I didn't look into it in more detail, but I think the
number of lines of code doesn't even come near to telling the whole
story.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
You liked Linux a lot when he was just the gawky kid from down the block
mowing your lawn or shoveling the snow. But now that he wants to date
your daughter, you're not so sure he measures up. (Larry Greenemeier)

Marc G. Fournier wrote:
> On Tue, 18 Nov 2003, Peter Eisentraut wrote:
>
> > 0. As you say, make it known to the public. Have people test their
> > in-development applications using a beta.
>
> and how do you propose we do that? I think this is the hard part ...
> other then the first beta, I post a note out to -announce and -general
> that the beta's have been tag'd and bundled for download ... I know Sean
> does up a 'devel' port for FreeBSD, but I don't believe any of the RPM/deb
> maintainers do anything until the final release ...
>
> > 1. Start platform testing on day 1 of beta. Last minute fixes for AIX
> > or UnixWare are really becoming old jokes.
>
> then each beta will have to be "re-certified" for that beta, up until
> release ... doable, but I don't think you'll find many that will bother
> until we are close to release ...
>
> > 2. Have a complete account of the changes available at the start of beta,
> > so people know what to test.
>
> Bruce, when do you do your initial HISTORY file? Something to move to the
> start of beta, if not?

I see beta starting on:

revision 1.277
date: 2003/08/04 22:30:30; author: pgsql; state: Exp; lines: +3 -3

change tag to 7.4beta1 and update the Copyright to 2003

Guess what folks? We are now in Beta!!

and 7.4 HISTORY updated on:

revision 1.196
date: 2003/08/03 23:26:05; author: momjian; state: Exp; lines: +324 -26
Update HISTORY file for 7.4.

so the HISTORY file was updated the day before beta started. I haven't
always been good about this, but I am now.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Guys,

I agree with Neil ... it's not the length of the development part of the
cycle, it's the length of the beta testing.

I do think an online bug tracker (bugzilla or whatever) would help. I also
think that having a person in charge of "testing" would help as well ... no
biggie, just someone whose duty it is to e-mail people in the community and
ask about the results of testing, especially on the more obscure ports. I
think a few e-mail reminders would do a *lot* to speed things up. But I'm
not volunteering for this job; managing the release PR is "herding cats"
enough!

I also contributed to the delays on this release because it took longer than I
expected to get the "PR machinery" started. We have a sort of system now,
though, and the next release should be easier.

HOWEVER, a release cycle of *less than 6 months* would kill the advocacy vols
if we wanted the same level of publicity.

I do support the idea of "dev" releases. For example, if there was a "dev"
release of PG+ARC as soon as Jan is done with it, I have one client would
would be willing to test it against a simulated production load on pretty
heavy-duty hardware.

(Oddly enough, my problem in doing more testing myself is external to
PostgreSQL; most of our apps are PHP apps and you can't compile PHP against
two different versions of PostgreSQL on the same server. Maybe with User
Mode Linux I'll be able to do more testing now.)

--
Josh Berkus
Aglio Database Solutions
San Francisco

On Tue, Nov 18, 2003 at 09:42:31AM -0800, Josh Berkus wrote:

> (Oddly enough, my problem in doing more testing myself is external to
> PostgreSQL; most of our apps are PHP apps and you can't compile PHP against
> two different versions of PostgreSQL on the same server. Maybe with User
> Mode Linux I'll be able to do more testing now.)

I'm not sure UML would help you here. I think you'd be better trying to
run Apache in a chrooted environment, PHP and PostgreSQL included. You
don't need another kernel, but another set of libraries.

BTW, I think UMLSIM (umlsim.sf.net) could help to play the
"unplug-the-server" game. In theory you could rewrite the block
subsystem to "fail", simulating a real disk failure and possible a
system shutdown. I don't have time to do it myself right now however ...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Find a bug in a program, and fix it, and the program will work today.
Show the program how to find and fix a bug, and the program
will work forever" (Oliver Silfridge)

Josh Berkus wrote:

>Guys,
>
>I agree with Neil ... it's not the length of the development part of the
>cycle, it's the length of the beta testing.
>
>I do think an online bug tracker (bugzilla or whatever) would help. I also
>think that having a person in charge of "testing" would help as well ... no
>biggie, just someone whose duty it is to e-mail people in the community and
>ask about the results of testing, especially on the more obscure ports. I
>think a few e-mail reminders would do a *lot* to speed things up. But I'm
>not volunteering for this job; managing the release PR is "herding cats"
>enough!
>

Maybe some sort of automated distributed build farm would be a good
idea. Check out http://build.samba.org/about.html to see how samba does
it (much lighter than the Mozilla tinderbox approach).

We wouldn't need to be as intensive as they appear to be - maybe a once
or twice a day download and test run would do the trick, but it could
pick up lots of breakage fairly quickly.

That is not to say that more intensive testing isn't also needed on
occasion.

cheers

andrew

On Tue, 18 Nov 2003, Andrew Dunstan wrote:

> Josh Berkus wrote:
>
> >Guys,
> >
> >I agree with Neil ... it's not the length of the development part of the
> >cycle, it's the length of the beta testing.
> >
> >I do think an online bug tracker (bugzilla or whatever) would help. I also
> >think that having a person in charge of "testing" would help as well ... no
> >biggie, just someone whose duty it is to e-mail people in the community and
> >ask about the results of testing, especially on the more obscure ports. I
> >think a few e-mail reminders would do a *lot* to speed things up. But I'm
> >not volunteering for this job; managing the release PR is "herding cats"
> >enough!
> >
>
> Maybe some sort of automated distributed build farm would be a good
> idea. Check out http://build.samba.org/about.html to see how samba does
> it (much lighter than the Mozilla tinderbox approach).
>
> We wouldn't need to be as intensive as they appear to be - maybe a once
> or twice a day download and test run would do the trick, but it could
> pick up lots of breakage fairly quickly.
>
> That is not to say that more intensive testing isn't also needed on
> occasion.

Check the archives on this, as its been hashed out already once at least
... I think the big issue/problem is that nobody seems able (or wants) to
come up with a script that could be setup in cron on machines to do this
... something simple that would dump the output to a log file and, if
regression tests failed, email'd the machine owner that it needs to be
checked would do, I would think ...

Marc G. Fournier wrote:

>On Tue, 18 Nov 2003, Andrew Dunstan wrote:
>
>
>
>>Maybe some sort of automated distributed build farm would be a good
>>idea. Check out http://build.samba.org/about.html to see how samba does
>>it (much lighter than the Mozilla tinderbox approach).
>>
>>We wouldn't need to be as intensive as they appear to be - maybe a once
>>or twice a day download and test run would do the trick, but it could
>>pick up lots of breakage fairly quickly.
>>
>>That is not to say that more intensive testing isn't also needed on
>>occasion.
>>
>>
>
>Check the archives on this, as its been hashed out already once at least
>... I think the big issue/problem is that nobody seems able (or wants) to
>come up with a script that could be setup in cron on machines to do this
>... something simple that would dump the output to a log file and, if
>regression tests failed, email'd the machine owner that it needs to be
>checked would do, I would think ...
>

If there's general interest I'll try to cook something up. (This kind of stuff is right up my alley). I'd prefer some automated display of results, though. A simple CGI script should be all that's required for that.

cheers

andrew

On Tue, 2003-11-18 at 14:36, Andrew Dunstan wrote:
> Marc G. Fournier wrote:
>
> >On Tue, 18 Nov 2003, Andrew Dunstan wrote:
> >
> >
> >
> >>Maybe some sort of automated distributed build farm would be a good
> >>idea. Check out http://build.samba.org/about.html to see how samba does
> >>it (much lighter than the Mozilla tinderbox approach).
> >>
> >>We wouldn't need to be as intensive as they appear to be - maybe a once
> >>or twice a day download and test run would do the trick, but it could
> >>pick up lots of breakage fairly quickly.
> >>
> >>That is not to say that more intensive testing isn't also needed on
> >>occasion.
> >>
> >>
> >
> >Check the archives on this, as its been hashed out already once at least
> >... I think the big issue/problem is that nobody seems able (or wants) to
> >come up with a script that could be setup in cron on machines to do this
> >... something simple that would dump the output to a log file and, if
> >regression tests failed, email'd the machine owner that it needs to be
> >checked would do, I would think ...
> >
>
> If there's general interest I'll try to cook something up. (This kind of stuff is right up my alley). I'd prefer some automated display of results, though. A simple CGI script should be all that's required for that.
>

look in the tools directory of cvs, i swear Bruce checked in a script he
uses for similar tasks..

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Robert Treat wrote:
> > >Check the archives on this, as its been hashed out already once at least
> > >... I think the big issue/problem is that nobody seems able (or wants) to
> > >come up with a script that could be setup in cron on machines to do this
> > >... something simple that would dump the output to a log file and, if
> > >regression tests failed, email'd the machine owner that it needs to be
> > >checked would do, I would think ...
> > >
> >
> > If there's general interest I'll try to cook something up. (This kind of stuff is right up my alley). I'd prefer some automated display of results, though. A simple CGI script should be all that's required for that.
> >
>
> look in the tools directory of cvs, i swear Bruce checked in a script he
> uses for similar tasks..

/tools/pgtest

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Wed, 19 Nov 2003, Christopher Kings-Lynne wrote:

> > HOWEVER, a release cycle of *less than 6 months* would kill the advocacy vols
> > if we wanted the same level of publicity.
> >
> > I do support the idea of "dev" releases. For example, if there was a "dev"
> > release of PG+ARC as soon as Jan is done with it, I have one client would
> > would be willing to test it against a simulated production load on pretty
> > heavy-duty hardware.
>
> Can't we have nightly builds always available? Why can't they just use
> the CVS version?

We do do nightly builds ... have for years now ...

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

> HOWEVER, a release cycle of *less than 6 months* would kill the advocacy vols
> if we wanted the same level of publicity.
>
> I do support the idea of "dev" releases. For example, if there was a "dev"
> release of PG+ARC as soon as Jan is done with it, I have one client would
> would be willing to test it against a simulated production load on pretty
> heavy-duty hardware.

Can't we have nightly builds always available? Why can't they just use
the CVS version?

> (Oddly enough, my problem in doing more testing myself is external to
> PostgreSQL; most of our apps are PHP apps and you can't compile PHP against
> two different versions of PostgreSQL on the same server. Maybe with User
> Mode Linux I'll be able to do more testing now.)

I'd be willing to give testing coordination a go, not sure where I'd
begin though.

Chris

Andrew Dunstan writes:

> If there's general interest I'll try to cook something up. (This kind of
> stuff is right up my alley). I'd prefer some automated display of
> results, though. A simple CGI script should be all that's required for
> that.

The real problem will be to find enough machines so that the build farm
becomes useful. IMO, that would mean *more* machines than are currently
lines in the supported-platforms table.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:

>Andrew Dunstan writes:
>
>
>
>>If there's general interest I'll try to cook something up. (This kind of
>>stuff is right up my alley). I'd prefer some automated display of
>>results, though. A simple CGI script should be all that's required for
>>that.
>>
>>
>
>The real problem will be to find enough machines so that the build farm
>becomes useful. IMO, that would mean *more* machines than are currently
>lines in the supported-platforms table.
>
>

"Useful" is probably subjective. That list would at least be a good
place to start, though. What combinations of variables do you think we
would need?

This would be a fairly painless way for users to be helpful to the
project, btw - the way I am envisioning things this would be fairly much
a "set and forget" process.

I'll have an example page available in a few days.

cheers

andrew

Marc G. Fournier wrote:

> On Tue, 18 Nov 2003, Peter Eisentraut wrote:
>
>> The time from release 7.3 to release 7.4 was 355 days, an all-time high.
>> We really need to shorten that. We already have a number of significant
>> improvements in 7.5 now, and several good ones coming up in the next few
>> weeks. We cannot let people wait 1 year for that. I suggest that we aim
>> for a 6 month cycle, consisting of approximately 4 months of development
>> and 2 months of cleanup. So the start of the next beta could be the 1st
>> of March. What do you think?
>
> That is the usual goal *nod* Same goal we try for each release, and never
> quite seem to get there ... we'll try 'yet again' with v7.5 though, as we
> always do :)

I don't see much of a point for a shorter release cycle as long as we
don't get rid of the initdb requirement for releases that don't change
the system catalog structure. All we gain from that is spreading out the
number of different versions used in production.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Andrew Dunstan writes:

> "Useful" is probably subjective. That list would at least be a good
> place to start, though. What combinations of variables do you think we
> would need?

First of all, I don't necessarily think that a large list of CPU/operation
system combinations is going to help much. IIRC, this round of platform
testing showed us two real problems, and both happened because the
operating system version in question came out the previous day, so we
could not have caught it. Much more problems arise when people use
different versions of secondary packages, such as Tcl, Perl, Kerberos,
Flex, Bison. So you would need to compile a large collection of these
things. The problem again is that it is usually the brand-new or the odd
intermediate version of such a tool that breaks things, so a "set and
forget" build farm is not going to catch it. Another real source of
problems are real systems. Weird combinations of packages, weird network
setups, weird applications, custom kernels. These cannot be detected on
out of the box setups. In fact, the regression tests might not detect
them at all.

Hence the open-source community approach. Closed-source development teams
can do all the above, with great effort. But by throwing out the code and
have real people test them on real systems with real applications, you can
do much better.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:

>Andrew Dunstan writes:
>
>
>
>>"Useful" is probably subjective. That list would at least be a good
>>place to start, though. What combinations of variables do you think we
>>would need?
>>
>>
>
>First of all, I don't necessarily think that a large list of CPU/operation
>system combinations is going to help much. IIRC, this round of platform
>testing showed us two real problems, and both happened because the
>operating system version in question came out the previous day, so we
>could not have caught it. Much more problems arise when people use
>different versions of secondary packages, such as Tcl, Perl, Kerberos,
>Flex, Bison. So you would need to compile a large collection of these
>things. The problem again is that it is usually the brand-new or the odd
>intermediate version of such a tool that breaks things, so a "set and
>forget" build farm is not going to catch it. Another real source of
>problems are real systems. Weird combinations of packages, weird network
>setups, weird applications, custom kernels. These cannot be detected on
>out of the box setups. In fact, the regression tests might not detect
>them at all.
>
>Hence the open-source community approach. Closed-source development teams
>can do all the above, with great effort. But by throwing out the code and
>have real people test them on real systems with real applications, you can
>do much better.
>
>
>

The fact that something doesn't find everything doesn't mean it is of no
value. (Thinks of Scott Adams' nice example: "Your theory of gravity
doesn't prove why there are no unicorns, so it is wrong." ;-) )

I don't believe there is a single "open source community" approach -
open source projects all have differing ways of handling problems. At
least 2 very significant open source projects I know of run build farms,
notwithstanding that your objections should apply equally to them.
Mozilla's is fairly centralised and very complex and heavy, but gives
fairly immediate feedback if anything gets broken. Samba's is much
lighter, distributed, and they still apparently see good value in it.
(Samba uses a "torture test" - perhaps we need one of those in addition
to the regression tests.)

Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I
have an open mind about it. I don't think incompleteness is an argument
against it, though.

cheers

andrew

Andrew Dunstan writes:

> Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I
> have an open mind about it. I don't think incompleteness is an argument
> against it, though.

If you want to do it, by all means go for it. I'm sure it would give
everyone a fuzzy feeling to see the green lights everywhere. But
realistically, don't expect any significant practical benefits, such
cutting beta time by 10%.

The Samba build daemon suite is pretty good. We have a couple of those
hosts in our office in fact. (I think they're building PostgreSQL
regularly as well.) A tip: You might find that adopting the source code
of the Samba suite to PostgreSQL is harder than writing a new one.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:

>The Samba build daemon suite is pretty good. We have a couple of those
>hosts in our office in fact. (I think they're building PostgreSQL
>regularly as well.) A tip: You might find that adopting the source code
>of the Samba suite to PostgreSQL is harder than writing a new one.
>
>

Yes, I agree. I have looked at it for ideas, but not for code. I'm not
using rsync or anything like that, for instance. I'm going for something
very simple to start with.

Essentially what I have is something like this pseudocode:

cvs update
check if there really was an update and if not exit
configure; get config.log
make 2>&1 | make-filter >makelog
make check 2>&1 | check-filter > checklog
(TBD) send config status, make status, check status, logfiles
make distclean

The send piece will probably be a perl script using LWP and talking to a
CGI script.

cheers

andrew

Andrew Dunstan writes:

> Essentially what I have is something like this pseudocode:
>
> cvs update

Be sure check past branches as well.

> check if there really was an update and if not exit

OK.

> configure; get config.log

Ideally, you'd try all possible option combinations for configure. Or at
least enable everything.

> make 2>&1 | make-filter >makelog
> make check 2>&1 | check-filter > checklog

You could also try out make distcheck. It tries out the complete build,
installation, uninstallation, regression test, and distribution building.

> (TBD) send config status, make status, check status, logfiles

OK.

> make distclean

When I played around with this, always copied the CVS tree to a new
directory and deleted that one at the end. That way, bugs in the clean
procedure (known to happen) don't trip up the whole process.

> The send piece will probably be a perl script using LWP and talking to a
> CGI script.

That will be the difficult part to organize, if it's supposed to be
distributed and autonomous.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Peter Eisentraut wrote:

>Andrew Dunstan writes:
>
>
>
>>Essentially what I have is something like this pseudocode:
>>
>> cvs update
>>
>>
>
>Be sure check past branches as well.
>
>
>
>> check if there really was an update and if not exit
>>
>>
>
>OK.
>
>
>
>> configure; get config.log
>>
>>
>
>Ideally, you'd try all possible option combinations for configure. Or at
>least enable everything.
>

I have had in mind from the start doing multiple configurations and
multiple branches.

Right now I'm working only with everything/head, but will make provision
for multiple sets of both.

How many branches back do you think should we go? Right now I'd be
inclined only to do REL7_4_STABLE and HEAD as a default. Maybe we could
set the default to be gettable from the web server so that as new
releases come along build farm members using the default wouldn't need
to make any changes.

However, everything would also be settable locally on each build farm
member in an options file.

>
>
>
>> make 2>&1 | make-filter >makelog
>> make check 2>&1 | check-filter > checklog
>>
>>
>
>You could also try out make distcheck. It tries out the complete build,
>installation, uninstallation, regression test, and distribution building.
>
>

OK.

>
>
>> (TBD) send config status, make status, check status, logfiles
>>
>>
>
>OK.
>
>
>
>> make distclean
>>
>>
>
>When I played around with this, always copied the CVS tree to a new
>directory and deleted that one at the end. That way, bugs in the clean
>procedure (known to happen) don't trip up the whole process.
>
>

OK. We've also seen odd problems with "cvs update", I seem to recall,
but I'd rather avoid having to fetch the entire tree for each run, to
keep bandwidth use down. (I believe "cvs update" should be fairly
reliable if there are no local changes, which would be true in this
instance).

>
>
>>The send piece will probably be a perl script using LWP and talking to a
>>CGI script.
>>
>>
>
>That will be the difficult part to organize, if it's supposed to be
>distributed and autonomous.
>
>

sending the results won't be a huge problem - storing and displaying
them nicely will be a bit more fun :-)

Upload of results would be over authenticated SSL to prevent spurious
results being fed to us - all you would need to join the build farm
would be a username/password from the buildfarm admin.

Thanks for your input

cheers

andrew

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> On Tue, 18 Nov 2003, Peter Eisentraut wrote:
>> The time from release 7.3 to release 7.4 was 355 days, an all-time high.
>> We really need to shorten that.

> I don't see much of a point for a shorter release cycle as long as we
> don't get rid of the initdb requirement for releases that don't change
> the system catalog structure. All we gain from that is spreading out the
> number of different versions used in production.

Yeah, I think the main issue in all this is that for real production
sites, upgrading Postgres across major releases is *painful*. We have
to find a solution to that before it makes sense to speed up the
major-release cycle.

By the same token, I'm not sure that there's much of a market for
"development" releases --- people who find a 7.3->7.4 upgrade painful
aren't going to want to add additional upgrades to incompatible
intermediate states. If we could fix that, there'd be more interest.

regards, tom lane

Kevin Brown <kevin(at)sysexperts(dot)com> writes:
> ... That's why the release methodology used by the Linux kernel development
> team is a reasonable one.

I do not think we have the manpower to manage multiple active
development branches. The Postgres developer community is a fraction of
the size of the Linux community; if we try to adopt what they do we'll
just drown in work. It's hard enough to deal with the existing level of
commitment to back-patching one stable release --- I know that we miss
back-patching bug fixes that probably should have been back-patched.
And the stuff that does get back-patched isn't really tested to the
level that it ought to be, which discourages us from applying fixes
to the stable branch if they are too large to be "obviously correct".
I don't see manpower emerging from the woodwork to fix those problems.

If we were doing active feature development in more than one branch
I think our process would break down completely.

regards, tom lane

Larry Rosenman <ler(at)lerctr(dot)org> writes:
> <peter_e(at)gmx(dot)net> wrote:
>> 1. Start platform testing on day 1 of beta. Last minute fixes for AIX or
>> UnixWare are really becoming old jokes.

> The only reason we had last minute stuff for UnixWare this time was the
> timing of PG's release and the UP3 release from SCO.

Yes. The late fixes for OS X also arose from the fact that Apple
released a new OS X version late in our beta cycle. I don't think it's
reasonable to complain that there was insufficient port testing done
earlier; the issues didn't come from that.

I do agree with the opinion that our beta cycles are getting too long,
and that it's not clear we are getting any additional reliability out
of the longer time period.

regards, tom lane

> Yeah, I think the main issue in all this is that for real production
> sites, upgrading Postgres across major releases is *painful*. We have
> to find a solution to that before it makes sense to speed up the
> major-release cycle.

Well, I think one of the simplest is to do a topological sort of objects
in pg_dump (between object classes that need it), AND regression
testing for pg_dump :)

Chris

On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote:
> >Yeah, I think the main issue in all this is that for real production
> >sites, upgrading Postgres across major releases is *painful*. We have
> >to find a solution to that before it makes sense to speed up the
> >major-release cycle.
>
> Well, I think one of the simplest is to do a topological sort of objects
> in pg_dump (between object classes that need it), AND regression
> testing for pg_dump :)

One of the most complex would be to avoid the need of pg_dump for
upgrades ...

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"I call it GNU/Linux. Except the GNU/ is silent." (Ben Reiter)

Alvaro Herrera wrote:

> On Fri, Nov 21, 2003 at 09:38:50AM +0800, Christopher Kings-Lynne wrote:
>> >Yeah, I think the main issue in all this is that for real production
>> >sites, upgrading Postgres across major releases is *painful*. We have
>> >to find a solution to that before it makes sense to speed up the
>> >major-release cycle.
>>
>> Well, I think one of the simplest is to do a topological sort of objects
>> in pg_dump (between object classes that need it), AND regression
>> testing for pg_dump :)
>
> One of the most complex would be to avoid the need of pg_dump for
> upgrades ...
>

We don't need a simple way, we need a way to create some sort of catalog
diff and "a safe" way to apply that to an existing installation during
the upgrade.

I think with a shutdown postmaster, a standalone backend used to check
that no conflicts exist in any DB, then using the new backend in
bootstrap mode to apply the changes, could be an idea to think of. It
would still require some downtime, but nobody can avoid that when
replacing the postgres binaries anyway, so that's not a real issue. As
long as it eliminates dump, initdb, reload it will be acceptable.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Andrew Dunstan writes:
>> Maybe it wouldn't be of great value to PostgreSQL. And maybe it would. I
>> have an open mind about it. I don't think incompleteness is an argument
>> against it, though.

> If you want to do it, by all means go for it. I'm sure it would give
> everyone a fuzzy feeling to see the green lights everywhere. But
> realistically, don't expect any significant practical benefits, such
> cutting beta time by 10%.

I think the main value of a build farm is that we'd get nearly immediate
feedback about the majority of simple porting problems. Your previous
arguments that it wouldn't smoke everything out are certainly valid ---
but we wouldn't abandon the regression tests just because they don't
find everything. Immediate feedback is good because a patch can be
fixed while it's still fresh in the author's mind.

I'm for it ...

regards, tom lane

Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> Alvaro Herrera wrote:
>> One of the most complex would be to avoid the need of pg_dump for
>> upgrades ...

> We don't need a simple way, we need a way to create some sort of catalog
> diff and "a safe" way to apply that to an existing installation during
> the upgrade.

I still think that pg_upgrade is the right idea: load a schema dump from
the old database into the new one, then transfer the user data files and
indexes via cheating (doubly linking, if possible). Obviously there is
a lot of work still to make this happen reliably, but we have seen
proof-of-concept some while ago, whereas "catalog diffs" are pie in the
sky IMHO. (You could not use either the old postmaster version or the
new version to apply such a diff...)

A big advantage of the pg_upgrade concept in my mind is that if it fails
partway through, you need have made no changes to the original
installation. Any mid-course problem with an in-place-diff approach
leaves you completely screwed :-(

regards, tom lane

Tom Lane wrote:

>
>I think the main value of a build farm is that we'd get nearly immediate
>feedback about the majority of simple porting problems. Your previous
>arguments that it wouldn't smoke everything out are certainly valid ---
>but we wouldn't abandon the regression tests just because they don't
>find everything. Immediate feedback is good because a patch can be
>fixed while it's still fresh in the author's mind.
>

Yes, I seem to recall seeing several instances of things like "you mean
foonix version 97 1/2 has a bad frobnitz.h?" over the last 6 months.
Having that caught early is exactly the advantage, I believe.

>
>I'm for it ...
>
>

I'm working on it :-)

Regarding "make distcheck" that Peter suggested I use, unless I'm
mistaken it carefully does its own configure, thus ignoring the
configure options set in the original directory. Perhaps we need either
to have the distcheck target pick up all the --with/--without and
--enable/--disable options, or to have a similar target that does that.

Thoughts?

cheers

andrew

Hello hackers

Sorry when I am talking to the gurus...

There is a database, which has a concept called "Transportable
Tablespace" (TTS). Would it not be a verry easy and fast solution to
just do this with the Tables, Index and all non catalog related files.
- You create a new db cluster (e.g 8.0).
- Generate a TTS export skript.
- Shut the (old) db-cluster (files should be consistent now, ev. do
something with the log files before).
- Move the files (eventually not needed) and
- plug it in to the new db cluster (via the export skript).

Expected downtime (without moving data files) 5-10 minutes.

Regards Oli

-------------------------------------------------------

Oli Sennhauser
Database-Engineer (Oracle & PostgreSQL)
Rebenweg 6
CH - 8610 Uster / Switzerland

Phone (+41) 1 940 24 82 or Mobile (+41) 79 450 49 14
e-Mail oli(dot)sennhauser(at)bluewin(dot)ch
Website http://mypage.bluewin.ch/shinguz/PostgreSQL/

Secure (signed/encrypted) e-Mail with a Free Personal SwissSign ID: http://www.swisssign.ch

Import the SwissSign Root Certificate: http://swisssign.net/cgi-bin/trust/import

Le Vendredi 21 Novembre 2003 19:47, Tom Lane a écrit :
> I think the main value of a build farm is that we'd get nearly immediate
> feedback about the majority of simple porting problems.  Your previous
> arguments that it wouldn't smoke everything out are certainly valid ---
> but we wouldn't abandon the regression tests just because they don't
> find everything.  Immediate feedback is good because a patch can be
> fixed while it's still fresh in the author's mind.

Dear friends,

We have a small build farm for pgAdmin covering Win32, FreeBSD and most GNU/
Linux systems. See http://www.pgadmin.org/pgadmin3/download.php#snapshots

The advantage are immediate feedback and correction of problems. Also, in a
release cycle, developers and translators are quite motivated to see their
work published fast.

Of course, it is always hard to "mesure" the real impact of a build farm. My
opinion it that it is quite positive, as it helps tighten the links between
people, which is free software is mostly about.

Cheers,
Jean-Michel Pouré

Jean-Michel POURE wrote:

>Le Vendredi 21 Novembre 2003 19:47, Tom Lane a écrit :
>
>
>>I think the main value of a build farm is that we'd get nearly immediate
>>feedback about the majority of simple porting problems. Your previous
>>arguments that it wouldn't smoke everything out are certainly valid ---
>>but we wouldn't abandon the regression tests just because they don't
>>find everything. Immediate feedback is good because a patch can be
>>fixed while it's still fresh in the author's mind.
>>
>>
>
>Dear friends,
>
>We have a small build farm for pgAdmin covering Win32, FreeBSD and most GNU/
>Linux systems. See http://www.pgadmin.org/pgadmin3/download.php#snapshots
>
>The advantage are immediate feedback and correction of problems. Also, in a
>release cycle, developers and translators are quite motivated to see their
>work published fast.
>
>Of course, it is always hard to "mesure" the real impact of a build farm. My
>opinion it that it is quite positive, as it helps tighten the links between
>people, which is free software is mostly about.
>
>
>

Right. But I think we have been talking about using the build farm to do
test builds rather than to provide snapshots. I'd be very wary of
providing arbitrary snapshots of postgres, whereas I'd be prepared to
try a snapshot of pgadmin3 under certain circumstances. (Also, building
your own snapshot of postgres is somewhat easier than building your own
snapshot of pgadmin3).

cheers

andrew

Andrew Dunstan wrote:

>
>
> Jean-Michel POURE wrote:
>
>> Le Vendredi 21 Novembre 2003 19:47, Tom Lane a écrit :
>>
>>
>>> I think the main value of a build farm is that we'd get nearly
>>> immediate
>>> feedback about the majority of simple porting problems. Your previous
>>> arguments that it wouldn't smoke everything out are certainly valid ---
>>> but we wouldn't abandon the regression tests just because they don't
>>> find everything. Immediate feedback is good because a patch can be
>>> fixed while it's still fresh in the author's mind.
>>>
>>
>>
>> Dear friends,
>>
>> We have a small build farm for pgAdmin covering Win32, FreeBSD and
>> most GNU/
>> Linux systems. See
>> http://www.pgadmin.org/pgadmin3/download.php#snapshots
>>
>> The advantage are immediate feedback and correction of problems.
>> Also, in a release cycle, developers and translators are quite
>> motivated to see their work published fast.
>> Of course, it is always hard to "mesure" the real impact of a build
>> farm. My opinion it that it is quite positive, as it helps tighten
>> the links between people, which is free software is mostly about.
>>
>>
>>
>
> Right. But I think we have been talking about using the build farm to
> do test builds rather than to provide snapshots. I'd be very wary of
> providing arbitrary snapshots of postgres, whereas I'd be prepared to
> try a snapshot of pgadmin3 under certain circumstances. (Also,
> building your own snapshot of postgres is somewhat easier than
> building your own snapshot of pgadmin3).

Testing a build and creating a snapshot compilation is quite the same,
just a different name and announcement. I agree that using a pgadmin
snapshot is different from pgsql, somebody using a bleeding edge pgsql
version should be prepared to compile it on his own machine.

And a tiny correction: The farm member for win32 is my machine, and it's
operated manually :-)

Regards,
Andreas

Le Lundi 24 Novembre 2003 16:38, Andreas Pflug a écrit :
> And a tiny correction: The farm member for win32 is my machine, and it's
> operated manually :-)

Some GNU/Linux farm animals are living in my garage running on very old 50
euros machines ... Ancient farming :-)

By the way, we would love if someone could provide pgAdmin3 daily snapshots
under other systems. The list of platforms can be viewed here, anyone is
welcome to provide additional ones:

http://www.pgadmin.org/pgadmin3/download.php#snapshots

Cheers, Jean-Michel

FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
directories for most of the machines, meaning you can CVS update once
and telnet in to compile for each platform.

---------------------------------------------------------------------------

Andrew Dunstan wrote:
> Tom Lane wrote:
>
> >
> >I think the main value of a build farm is that we'd get nearly immediate
> >feedback about the majority of simple porting problems. Your previous
> >arguments that it wouldn't smoke everything out are certainly valid ---
> >but we wouldn't abandon the regression tests just because they don't
> >find everything. Immediate feedback is good because a patch can be
> >fixed while it's still fresh in the author's mind.
> >
>
> Yes, I seem to recall seeing several instances of things like "you mean
> foonix version 97 1/2 has a bad frobnitz.h?" over the last 6 months.
> Having that caught early is exactly the advantage, I believe.
>
> >
> >I'm for it ...
> >
> >
>
> I'm working on it :-)
>
> Regarding "make distcheck" that Peter suggested I use, unless I'm
> mistaken it carefully does its own configure, thus ignoring the
> configure options set in the original directory. Perhaps we need either
> to have the distcheck target pick up all the --with/--without and
> --enable/--disable options, or to have a similar target that does that.
>
> Thoughts?
>
> cheers
>
> andrew
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Wed, Nov 19, 2003 at 04:34:27PM +0100, Peter Eisentraut wrote:
> Hence the open-source community approach. Closed-source development teams
> can do all the above, with great effort. But by throwing out the code and
> have real people test them on real systems with real applications, you can
> do much better.

Would it be reasonable to promote users testing daily snapshots with
popular applications? I'm guessing there's not many applications that
have automated test frameworks, but any that do would theoretically
provide another good test of PGSQL changes.
--
Jim C. Nasby, Database Consultant jim(at)nasby(dot)net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

> Would it be reasonable to promote users testing daily snapshots with
> popular applications? I'm guessing there's not many applications that
> have automated test frameworks, but any that do would theoretically
> provide another good test of PGSQL changes.

May I quote Joel on Software here?

http://www.joelonsoftware.com/articles/fog0000000043.html

The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?

"The neat thing about The Joel Test is that it's easy to get a quick yes
or no to each question. You don't have to figure out
lines-of-code-per-day or average-bugs-per-inflection-point. Give your
team 1 point for each "yes" answer. The bummer about The Joel Test is
that you really shouldn't use it to make sure that your nuclear power
plant software is safe.

A score of 12 is perfect, 11 is tolerable, but 10 or lower and you've
got serious problems. The truth is that most software organizations are
running with a score of 2 or 3, and they need serious help, because
companies like Microsoft run at 12 full-time. "

Not everything there applies to us, of course.

Chris

On Fri, Nov 21, 2003 at 01:32:38PM -0500, Jan Wieck wrote:
> bootstrap mode to apply the changes, could be an idea to think of. It
> would still require some downtime, but nobody can avoid that when
> replacing the postgres binaries anyway, so that's not a real issue. As
> long as it eliminates dump, initdb, reload it will be acceptable.

Has anyone looked at using replication as a migration method? If
replication can be setup in such a way that you can replicate from an
old version to a new version, you can use that to build the new version
of the database on a seperate machine/instance while the old version is
still live. With some sophisticated middleware, you could theoretically
migrate without any downtime.
--
Jim C. Nasby, Database Consultant jim(at)nasby(dot)net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

Quoth jim(at)nasby(dot)net ("Jim C. Nasby"):
> On Fri, Nov 21, 2003 at 01:32:38PM -0500, Jan Wieck wrote:
>> bootstrap mode to apply the changes, could be an idea to think of. It
>> would still require some downtime, but nobody can avoid that when
>> replacing the postgres binaries anyway, so that's not a real issue. As
>> long as it eliminates dump, initdb, reload it will be acceptable.
>
> Has anyone looked at using replication as a migration method? If
> replication can be setup in such a way that you can replicate from an
> old version to a new version, you can use that to build the new version
> of the database on a seperate machine/instance while the old version is
> still live. With some sophisticated middleware, you could theoretically
> migrate without any downtime.

The idea has indeed been "looked at," and seems pretty feasible.

It would certainly take some sophisticated middleware to totally evade
downtime. But replicating from "old version" to "new version" does
have the merit of keeping the downtime to fairly much a minimum.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www3.sympatico.ca/cbbrowne/x.html
:FATAL ERROR -- VECTOR OUT OF HILBERT SPACE

Bruce Momjian writes:

> FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
> directories for most of the machines, meaning you can CVS update once
> and telnet in to compile for each platform.

Except that you can't open connections to the outside from these machines.

--
Peter Eisentraut peter_e(at)gmx(dot)net

Bruce Momjian wrote:

>FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
>directories for most of the machines, meaning you can CVS update once
>and telnet in to compile for each platform.
>
>
>

As Peter pointed out, these machines are firewalled. But presumably one could upload a snapshot to them. What I had in mind was a more distributed system, though.

Of course, these things are not mutually exclusive - using the HP testdrive farm looks like it might be nice. But it would be hard to automate, I suspect.

cheers

andrew

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
> > directories for most of the machines, meaning you can CVS update once
> > and telnet in to compile for each platform.
>
> Except that you can't open connections to the outside from these machines.

Oh, yea. You can connect to the machines with ftp, so I guess you would
have to CVS update on your local machine, then push the changes to the
farm.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Andrew Dunstan wrote:
> Bruce Momjian wrote:
>
> >FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
> >directories for most of the machines, meaning you can CVS update once
> >and telnet in to compile for each platform.
> >
> >
> >
>
> As Peter pointed out, these machines are firewalled. But presumably
> one could upload a snapshot to them. What I had in mind was a
> more distributed system, though.
>
> Of course, these things are not mutually exclusive - using the
> HP testdrive farm looks like it might be nice. But it would be
> hard to automate, I suspect.

I figured you could just upload once and telnet and build on each
machine.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

>Andrew Dunstan wrote:
>
>
>>Bruce Momjian wrote:
>>
>>
>>
>>>FYI, the HP testdrive farm, http://www.testdrive.hp.com, has shared
>>>directories for most of the machines, meaning you can CVS update once
>>>and telnet in to compile for each platform.
>>>
>>>
>>>
>>>
>>>
>>As Peter pointed out, these machines are firewalled. But presumably
>>one could upload a snapshot to them. What I had in mind was a
>>more distributed system, though.
>>
>>Of course, these things are not mutually exclusive - using the
>>HP testdrive farm looks like it might be nice. But it would be
>>hard to automate, I suspect.
>>
>>
>
>I figured you could just upload once and telnet and build on each
>machine.
>
>
>

What I'm working on (slowly - I'm quite busy right now, and about to be
away from home for 5 days) is a system which would (or could) run from
cron on every member of the farm, and upload its results to a central
server where it could be displayed, in a somewhat similar way to the way
the Samba build farm works - see http://build.samba.org/ - so we'd be
able to see at a glance when something is broken and where and why. We
could also incorporate email notification of breakage, as a refinement.

I have a few pieces of this working but not a full suite yet - it will
essentially be 3 perl scripts - one on the client (to run the update(s),
build(s) and upload the results) and two on the central server (one for
upload and one for display). When I get a demo page done I'll show it
working with a couple of hosts.

Of course, you can automate (almost) anything, including telnet, but
right now I'm assuming the farm members will have internet connectivity.

cheers

andrew

On Mon, Nov 24, 2003 at 11:08:44PM -0600, Jim C. Nasby wrote:

> Has anyone looked at using replication as a migration method? If

Looked at? Sure. Heck, I've done it. Yes, it works. Is it
painless? Well, that depends on whether you think using erserver is
painless. ;-) It's rather less downtime than pg_dump | psql, I'll
tell you.

A

--
----
Andrew Sullivan 204-4141 Yonge Street
Afilias Canada Toronto, Ontario Canada
<andrew(at)libertyrms(dot)info> M2P 2A8
+1 416 646 3304 x110

Just a thought. You could also run the regression test automatically after a
successful build?

"Andrew Dunstan" <andrew(at)dunslane(dot)net> wrote in message
news:3FC1FFA5(dot)9030003(at)dunslane(dot)net(dot)(dot)(dot)
>
>
> Jean-Michel POURE wrote:
>
> >Le Vendredi 21 Novembre 2003 19:47, Tom Lane a crit :
> >
> >
> >>I think the main value of a build farm is that we'd get nearly immediate
> >>feedback about the majority of simple porting problems. Your previous
> >>arguments that it wouldn't smoke everything out are certainly valid ---
> >>but we wouldn't abandon the regression tests just because they don't
> >>find everything. Immediate feedback is good because a patch can be
> >>fixed while it's still fresh in the author's mind.
> >>
> >>
> >
> >Dear friends,
> >
> >We have a small build farm for pgAdmin covering Win32, FreeBSD and most
GNU/
> >Linux systems. See http://www.pgadmin.org/pgadmin3/download.php#snapshots
> >
> >The advantage are immediate feedback and correction of problems. Also, in
a
> >release cycle, developers and translators are quite motivated to see
their
> >work published fast.
> >
> >Of course, it is always hard to "mesure" the real impact of a build farm.
My
> >opinion it that it is quite positive, as it helps tighten the links
between
> >people, which is free software is mostly about.
> >
> >
> >
>
> Right. But I think we have been talking about using the build farm to do
> test builds rather than to provide snapshots. I'd be very wary of
> providing arbitrary snapshots of postgres, whereas I'd be prepared to
> try a snapshot of pgadmin3 under certain circumstances. (Also, building
> your own snapshot of postgres is somewhat easier than building your own
> snapshot of pgadmin3).
>
> cheers
>
> andrew
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

Any chance you might be able to put together a HOWTO on this? I think it
would be extremely valuable to a lot of people.

On Tue, Nov 25, 2003 at 11:25:34PM -0500, Andrew Sullivan wrote:
> On Mon, Nov 24, 2003 at 11:08:44PM -0600, Jim C. Nasby wrote:
>
> > Has anyone looked at using replication as a migration method? If
>
> Looked at? Sure. Heck, I've done it. Yes, it works. Is it
> painless? Well, that depends on whether you think using erserver is
> painless. ;-) It's rather less downtime than pg_dump | psql, I'll
> tell you.
--
Jim C. Nasby, Database Consultant jim(at)nasby(dot)net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"