Subject: Release cycle length

From: Peter Eisentraut <[email-masked]>
Date: Tue, 18 Nov 2003 00:46:38 +0100 (CET)

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   [email-masked]

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 17 Nov 2003 20:24:21 -0400 (AST)

> 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 :)

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 18 Nov 2003 01:44:48 +0100 (CET)

Marc G. Fournier writes:

> 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.

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 17 Nov 2003 20:47:08 -0400 (AST)

> Part of that may have been that few people were actually aware of that

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 ...

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 17 Nov 2003 20:58:26 -0400 (AST)

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

> done' at the end that pushes it further then originally planned ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: [email-masked]           Yahoo!: yscrappy              ICQ: 7615664

---

From: Neil Conway <[email-masked]>
Date: Mon, 17 Nov 2003 20:08:41 -0500

Peter Eisentraut <[email-masked]> 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

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 18 Nov 2003 02:12:09 +0100 (CET)

> 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. ;-)

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 18 Nov 2003 02:21:45 +0100 (CET)

> > high.  We really need to shorten 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.

---

From: Christopher Kings-Lynne <[email-masked]>
Date: Tue, 18 Nov 2003 09:46:06 +0800

> 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

---

From: Christopher Kings-Lynne <[email-masked]>
Date: Tue, 18 Nov 2003 09:48:11 +0800

> 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

---

From: "Joshua D. Drake" <[email-masked]>
Date: Mon, 17 Nov 2003 17:58:20 -0800

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

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

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 17 Nov 2003 22:22:12 -0400 (AST)

> 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

---

From: Doug McNaught <[email-masked]>
Date: 17 Nov 2003 21:26:09 -0500

> 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

---

From: Christopher Kings-Lynne <[email-masked]>
Date: Tue, 18 Nov 2003 10:32:56 +0800

> 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

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 18 Nov 2003 03:33:25 +0100 (CET)

> 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.

---

From: Neil Conway <[email-masked]>
Date: Mon, 17 Nov 2003 21:33:30 -0500

Peter Eisentraut <[email-masked]> writes:
> 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

---

From: "Matthew T. O'Connor" <[email-masked]>
Date: Mon, 17 Nov 2003 21:49:28 -0500

>middle of July, everyone is on vacation, and we'll easily reach the 9
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.

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 17 Nov 2003 23:00:01 -0400 (AST)

> middle of July, everyone is on vacation, and we'll easily reach the 9

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

---

From: Neil Conway <[email-masked]>
Date: Mon, 17 Nov 2003 22:10:20 -0500

"Matthew T. O'Connor" <[email-masked]> 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

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

---

From: Kevin Brown <[email-masked]>
Date: Mon, 17 Nov 2003 19:21:23 -0800

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

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

>       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.

> 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.

> 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					      [email-masked]

---

From: Kevin Brown <[email-masked]>
Date: Mon, 17 Nov 2003 19:26:20 -0800

> 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..

---

From: Christopher Kings-Lynne <[email-masked]>
Date: Tue, 18 Nov 2003 11:32:25 +0800

> 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

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 18 Nov 2003 04:43:12 +0100 (CET)

> 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.

---

From: "Marc G. Fournier" <[email-masked]>
Date: Mon, 17 Nov 2003 23:46:46 -0400 (AST)

> 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?

---

From: Christopher Kings-Lynne <[email-masked]>
Date: Tue, 18 Nov 2003 11:58:59 +0800

> 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

---

From: Larry Rosenman <[email-masked]>
Date: Mon, 17 Nov 2003 22:07:54 -0600

>    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: [email-masked]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 18 Nov 2003 00:36:11 -0400 (AST)

>    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 ...

>    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

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

>    proposals for open issues fielded then, string freeze 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 ...

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 18 Nov 2003 00:36:48 -0400 (AST)

> 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 :(

---

From: Neil Conway <[email-masked]>
Date: Tue, 18 Nov 2003 00:53:12 -0500

"Marc G. Fournier" <[email-masked]> writes:
> 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

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 18 Nov 2003 02:00:56 -0400 (AST)

>     There are probably other software release announcement sites we

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

>     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'
...

---

From: elein <[email-masked]>
Date: Mon, 17 Nov 2003 22:57:20 -0800

> 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

=============================================================
[email-masked]       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.

---

From: Oliver Elphick <[email-masked]>
Date: Tue, 18 Nov 2003 10:02:15 +0000

> 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                                [email-masked]
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

---

From: Sean Chittenden <[email-masked]>
Date: Tue, 18 Nov 2003 02:41:01 -0800

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

> 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@pgsql is the same
as trb@FreeBSD + core@FreeBSD + re@FreeBSD + qa@FreeBSD.  I think that
core@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

---

From: Bruno Wolff III <[email-masked]>
Date: Tue, 18 Nov 2003 07:18:27 -0600

On Mon, Nov 17, 2003 at 20:08:41 -0500,
> > high.  We really need to shorten 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.

---

From: Tommi Maekitalo <[email-masked]>
Date: Tue, 18 Nov 2003 14:33:41 +0100

...
> 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

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 18 Nov 2003 10:44:54 -0300

> 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)

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 18 Nov 2003 09:51:03 -0500 (EST)

> Bruce, when do you do your initial HISTORY file?  Something to move to the

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
  [email-masked]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---

From: Josh Berkus <[email-masked]>
Date: Tue, 18 Nov 2003 09:42:31 -0800

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

---

From: Alvaro Herrera <[email-masked]>
Date: Tue, 18 Nov 2003 15:17:50 -0300

> 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)

---

From: Andrew Dunstan <[email-masked]>
Date: Tue, 18 Nov 2003 13:48:57 -0500

>not volunteering for this job; managing the release PR is "herding cats" 

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

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 18 Nov 2003 15:13:52 -0400 (AST)

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

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 ...

---

From: Andrew Dunstan <[email-masked]>
Date: Tue, 18 Nov 2003 14:36:23 -0500

>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

---

From: Robert Treat <[email-masked]>
Date: 18 Nov 2003 17:12:26 -0500

> 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…

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

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 18 Nov 2003 20:09:53 -0500 (EST)

> look in the tools directory of cvs, i swear Bruce checked in a script he

/tools/pgtest

---

From: "Marc G. Fournier" <[email-masked]>
Date: Tue, 18 Nov 2003 21:56:48 -0400 (AST)

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

> 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 ...

----

---

From: Christopher Kings-Lynne <[email-masked]>
Date: Wed, 19 Nov 2003 09:56:55 +0800

> 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

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 19 Nov 2003 10:11:55 +0100 (CET)

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.

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 19 Nov 2003 07:59:54 -0500

>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

---

From: Jan Wieck <[email-masked]>
Date: Wed, 19 Nov 2003 09:33:04 -0500

> quite seem to get there ... we'll try 'yet again' with v7.5 though, as we

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.                                  #
#================================================== [email-masked] #

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 19 Nov 2003 16:34:27 +0100 (CET)

> place to start, though. What combinations of variables do you think we

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.

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 19 Nov 2003 12:18:00 -0500

>have real people test them on real systems with real applications, you can

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

---

From: Peter Eisentraut <[email-masked]>
Date: Wed, 19 Nov 2003 19:18:28 +0100 (CET)

> have an open mind about it. I don't think incompleteness is an argument

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.

---

From: Andrew Dunstan <[email-masked]>
Date: Wed, 19 Nov 2003 14:27:31 -0500

>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

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 20 Nov 2003 00:42:58 +0100 (CET)

> Essentially what I have is something like this pseudocode:

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 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

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

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 20 Nov 2003 09:58:33 -0500

>Ideally, you'd try all possible option combinations for configure.  Or at

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.

OK.

>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).

>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

---

From: Tom Lane <[email-masked]>
Date: Thu, 20 Nov 2003 15:19:38 -0500

Jan Wieck <[email-masked]> writes:
>> We really need to shorten that.

> 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

---

From: Tom Lane <[email-masked]>
Date: Thu, 20 Nov 2003 15:33:15 -0500

Kevin Brown <[email-masked]> 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

---

From: Tom Lane <[email-masked]>
Date: Thu, 20 Nov 2003 15:38:05 -0500

> 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

---

From: Christopher Kings-Lynne <[email-masked]>
Date: Fri, 21 Nov 2003 09:38:50 +0800

> to find a solution to that before it makes sense to speed up the

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

---

From: Alvaro Herrera <[email-masked]>
Date: Fri, 21 Nov 2003 10:03:59 -0300

>  in pg_dump (between object classes that need it), AND regression 

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

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

---

From: Jan Wieck <[email-masked]>
Date: Fri, 21 Nov 2003 13:32:38 -0500

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

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

---

From: Tom Lane <[email-masked]>
Date: Fri, 21 Nov 2003 13:47:48 -0500

> 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

---

From: Tom Lane <[email-masked]>
Date: Fri, 21 Nov 2003 14:08:28 -0500

> diff and "a safe" way to apply that to an existing installation during 

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

---

From: Andrew Dunstan <[email-masked]>
Date: Fri, 21 Nov 2003 14:39:39 -0500

>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

---

From: Oli Sennhauser <[email-masked]>
Date: Fri, 21 Nov 2003 22:18:26 +0100

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 [email-masked]
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

---

From: Jean-Michel POURE <[email-masked]>
Date: Mon, 24 Nov 2003 10:14:48 +0100

> 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é

---

From: Andrew Dunstan <[email-masked]>
Date: Mon, 24 Nov 2003 07:55:01 -0500

>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

---

From: Andreas Pflug <[email-masked]>
Date: Mon, 24 Nov 2003 16:38:20 +0100

Andrew Dunstan wrote:

>> 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 
> 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

---

From: Jean-Michel POURE <[email-masked]>
Date: Mon, 24 Nov 2003 17:20:17 +0100

> And a tiny correction: The farm member for win32 is my machine, and it's

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:

Cheers, Jean-Michel

---

From: Bruce Momjian <[email-masked]>
Date: Mon, 24 Nov 2003 21:10:49 -0500 (EST)

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:
> TIP 7: don't forget to increase your free space map settings
>

---

From: "Jim C. Nasby" <[email-masked]>
Date: Mon, 24 Nov 2003 22:42:45 -0600

> have real people test them on real systems with real applications, you can
 
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                  [email-masked]
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?"

---

From: Christopher Kings-Lynne <[email-masked]>
Date: Tue, 25 Nov 2003 13:05:11 +0800

> 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

---

From: "Jim C. Nasby" <[email-masked]>
Date: Mon, 24 Nov 2003 23:08:44 -0600

> 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                  [email-masked]
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

---

From: Christopher Browne <[email-masked]>
Date: Tue, 25 Nov 2003 00:51:05 -0500

> 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

---

From: Peter Eisentraut <[email-masked]>
Date: Tue, 25 Nov 2003 07:48:03 +0100 (CET)

> and telnet in to compile for each platform.

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

---

From: Andrew Dunstan <[email-masked]>
Date: Tue, 25 Nov 2003 09:49:33 -0500

>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

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 25 Nov 2003 10:14:50 -0500 (EST)

> 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.

---

From: Bruce Momjian <[email-masked]>
Date: Tue, 25 Nov 2003 11:42:57 -0500 (EST)

Andrew Dunstan wrote:
> 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.

---

From: Andrew Dunstan <[email-masked]>
Date: Tue, 25 Nov 2003 12:23:06 -0500

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

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Nov 2003 23:25:34 -0500

> 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
<[email-masked]>                              M2P 2A8
                                         +1 416 646 3304 x110

---

From: "nobody" <[email-masked]>
Date: Wed, 26 Nov 2003 17:17:26 -0000

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

"Andrew Dunstan" <[email-masked]> wrote in message
news:[email-masked]...
> TIP 3: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to [email-masked] so that your
>       message can get through to the mailing list cleanly
>

---

From: "Jim C. Nasby" <[email-masked]>
Date: Mon, 8 Dec 2003 18:49:31 -0600

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.