First, let me say that our 7.2 release was a huge success.  It was of
very high quality and well received by the community.

I want to address a concern I have heard from many of you --- the long
duration of the beta period.  I think there are two major causes. 
First, the quality of our releases continues to increase, and quality
takes time.  We may get to a point where all we do is "polish" from
release to release.  Seriously, the time we spend polishing will
continue to increase because our quality continues to increase.

Second, I think there was a certain disorganization in our previous beta
period that greatly lengthened it.  We didn't set any beta deadlines, we
didn't have a web page showing the open beta items, and no one was
really pushing and rallying the troops to get the beta out.  I am going
to try to correct this by giving more direction to the group and
maintaining a beta open items web page where people can go to see the
current beta status.  I don't know if this will help, but I think it
should be attempted to see if more organization can help us be more
effective.  Obviously, we are mostly volunteers, but I think
organization can shorten future beta periods.

Future directions
-----------------
Here is my guess on our future timetable.  These dates are mostly
arbitrary, but I think it will help give people an idea of where we are
going.  I think we will remain in our current development mode through
May or even July.  At that time, we will enter beta in 7.3.  I will
create an open items web page for the beta, and we will try to set a
timetable for the end of beta.  We will not be tied to that date, but I
think setting a date will help us better focus our energies and get the
beta out the door faster.

My proposal is that we give this a try and see if it speeds up the beta
period, and makes it more enjoyable.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 23 Feb 2002 22:58:25 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Duration of beta period
On Sat, 23 Feb 2002, Bruce Momjian wrote:

> First, let me say that our 7.2 release was a huge success.  It was of
> very high quality and well received by the community.
>
> I want to address a concern I have heard from many of you --- the long
> duration of the beta period.  I think there are two major causes.
> First, the quality of our releases continues to increase, and quality
> takes time.  We may get to a point where all we do is "polish" from
> release to release.  Seriously, the time we spend polishing will
> continue to increase because our quality continues to increase.
>
> Second, I think there was a certain disorganization in our previous beta
> period that greatly lengthened it.  We didn't set any beta deadlines, we
> didn't have a web page showing the open beta items, and no one was
> really pushing and rallying the troops to get the beta out.  I am going
> to try to correct this by giving more direction to the group and
> maintaining a beta open items web page where people can go to see the
> current beta status.  I don't know if this will help, but I think it
> should be attempted to see if more organization can help us be more
> effective.  Obviously, we are mostly volunteers, but I think
> organization can shorten future beta periods.
>
> Future directions
> -----------------
> Here is my guess on our future timetable.  These dates are mostly
> arbitrary, but I think it will help give people an idea of where we are
> going.  I think we will remain in our current development mode through
> May or even July.  At that time, we will enter beta in 7.3.  I will
> create an open items web page for the beta, and we will try to set a
> timetable for the end of beta.  We will not be tied to that date, but I
> think setting a date will help us better focus our energies and get the
> beta out the door faster.
>
> My proposal is that we give this a try and see if it speeds up the beta
> period, and makes it more enjoyable.

You've totally lost me here ... how do you speed up a beta when there are
unknown number of bugs that have to be resolved before a release can
happen?  A beta's duration is as long as it takes to be stable ...

Personally, I think this last beta period was one of our best ones yet ...
considering the negligible number of bug reports following the release, we
did exactly what had to be done in teh beta to make sure that the end
result was as stable as possible for the testing pool we had ...

Don't start trying to set arbitrary dates on when a beta should start, or
end ... you'll just screw with what is already a very effective
development model ...

If you are so bored that you need to organize something, come up with a
list of what we hope to accomplish for v7.3 and use that for a guideline
for when the beta will start ...

What major items do ppl have planned for v7.3?  Once those items are
completed, then we go into beta for v7.3 and beta lasts until we've gotten
her to the point that she's as bug free as she can be without more
extensive/broader testing ...

If those major items are done on the 1st of April, I'll happily declare it
the shortest development cycle we've had to date and go beta ... if it
takes until the 1st of September, so be it ... but its not going to go
beta until its ready, and its not going to be released until its ready ...
and setting some arbitrary date is going to do one of two things:  a)
pressure developers into making mistakes that will make us look bad, or b)
stiffle development while one developer figures "no way I'll get it done
by then, so why bother" ...

... and that isn't to throw in the users that are going to say "but you
said ... "




Sun, 24 Feb 2002 00:15:48 -0400 (AST)
"Marc G. Fournier" <scrappy@hub.org>
Re: Duration of beta period
> You've totally lost me here ... how do you speed up a beta when there are
> unknown number of bugs that have to be resolved before a release can
> happen?  A beta's duration is as long as it takes to be stable ...
> 
> Personally, I think this last beta period was one of our best ones yet ...
> considering the negligible number of bug reports following the release, we
> did exactly what had to be done in teh beta to make sure that the end
> result was as stable as possible for the testing pool we had ...

It was a good period, but we were in beta longer than we were in
development.  That isn't good, and I think we could have shortened it if
we had pushed people to test beta sooner and harder, avoided some
sideroads in improving things that could have waited for 7.3, and pushed
a few people to complete bug fixes quicker than letting it all wait
until the end of beta.  Of course, I may be wrong.  :-)

> Don't start trying to set arbitrary dates on when a beta should start, or
> end ... you'll just screw with what is already a very effective
> development model ...

I sensed people were not happy with the beta duration. I think it was
sort of like being on a baseball team, and someone hits the ball to an
outfielder, and they drop it, and you feel, "Hey, my team stinks." 
People like to be in groups that can successfully get things done, and
in a timely manner.  No one wants to wait for the last person to get in
the bus so we can leave.  If we don't tell people when the bus is
leaving, and just say, hey, get on the bus as soon as you can, it
doesn't seem to work as well as saying, "We are leaving in one hour.  Be
on the bus, or explain why we should wait another hour."  Of course,
just an analogy, but I think it has a point.

> If you are so bored that you need to organize something, come up with a
> list of what we hope to accomplish for v7.3 and use that for a guideline
> for when the beta will start ...

That is a tough one, and something that seems very hard to organize, but
I can try if you wish.  The TODO list can easily be used for that.
Another marking stating "Will be done for 7.3" is all it needs.  When
all the marks are turned to dashes (done) we are ready for beta.

> What major items do ppl have planned for v7.3?  Once those items are
> completed, then we go into beta for v7.3 and beta lasts until we've gotten
> her to the point that she's as bug free as she can be without more
> extensive/broader testing ...

That is a good question and something we do need to ask.  Thanks.

> If those major items are done on the 1st of April, I'll happily declare it
> the shortest development cycle we've had to date and go beta ... if it
> takes until the 1st of September, so be it ... but its not going to go
> beta until its ready, and its not going to be released until its ready ...
> and setting some arbitrary date is going to do one of two things:  a)
> pressure developers into making mistakes that will make us look bad, or b)
> stiffle development while one developer figures "no way I'll get it done
> by then, so why bother" ...

Agreed, don't release until it is ready, but I think we could make it
ready faster with some dates.  I am feeling people are doing beta
testing only near the end of beta because they realize how long it is
taking.  That is bad.  There is always pressure to lengthen the
schedule.  I think we need some pressure to shorten it.  That is all I
am saying.

> ... and that isn't to throw in the users that are going to say "but you
> said ... "

Agreed, we certainly want to stay away from that --- users holding us to
our dates is a recipe for disaster.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sat, 23 Feb 2002 23:27:39 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Duration of beta period
On Sat, 23 Feb 2002, Bruce Momjian wrote:

> > You've totally lost me here ... how do you speed up a beta when there are
> > unknown number of bugs that have to be resolved before a release can
> > happen?  A beta's duration is as long as it takes to be stable ...
> >
> > Personally, I think this last beta period was one of our best ones yet ...
> > considering the negligible number of bug reports following the release, we
> > did exactly what had to be done in teh beta to make sure that the end
> > result was as stable as possible for the testing pool we had ...
>
> It was a good period, but we were in beta longer than we were in
> development.  That isn't good, and I think we could have shortened it if
> we had pushed people to test beta sooner and harder, avoided some
> sideroads in improving things that could have waited for 7.3, and pushed
> a few people to complete bug fixes quicker than letting it all wait
> until the end of beta.  Of course, I may be wrong.  :-)

Where this a commercial product, your assessments would be correct ...
but, alas, we aren't ... "pushing ppl" that are doing something because
they enjoy it, and receive no compensation for it, is a very effective way
of driving good ppl away ...

> > Don't start trying to set arbitrary dates on when a beta should start, or
> > end ... you'll just screw with what is already a very effective
> > development model ...
>
> I sensed people were not happy with the beta duration. I think it was
> sort of like being on a baseball team, and someone hits the ball to an
> outfielder, and they drop it, and you feel, "Hey, my team stinks."
> People like to be in groups that can successfully get things done, and
> in a timely manner.  No one wants to wait for the last person to get in
> the bus so we can leave.  If we don't tell people when the bus is
> leaving, and just say, hey, get on the bus as soon as you can, it
> doesn't seem to work as well as saying, "We are leaving in one hour.  Be
> on the bus, or explain why we should wait another hour."  Of course,
> just an analogy, but I think it has a point.

Again, great one for a commercial product, totally inappropriate for us
... and even for a commercial product, I dont' think it works unless you
want to have your paying clients go to someone else cause of all the bugs
...

You can't, and won't, force someone to fix bugs just because you've set a
date for them ... and you cna't put out a product without the known bugs
fixed, unless you want to lose marketshare ...

We aren't a 20k line C program where the effects of fixing one thing won't
affect somewhere else ... how many long discussions were there during the
beta period this time where the ramifications of that change wouldn't be
felt in other places?

We are no longer in the "let's fix a bunch of bugs and call it a release"
mode ... there are *alot* of *very* large changes that have gone into each
consecutive release, the code base is getting gradually larger, and the
ramifications of the changes are getting more diverse ...

God, I can remember a time when Oleg's group submitting a patch for the
GiST stuff would have been shoved in during beta cause, hell, it didn't
work anyway ... now we look at it sideways and say it has to wait until
the next dev cycle ...

Do not set 'timeline's, set 'milestones' ... generate a listing of what
ppl are working on for v7.3, follow that development and when its done,
*then* its time for beta ... if that is 6-8's down the road, so be it ...
that is why projects like FreeBSD have a -STABLE vs -CURRENT branch, so
that the big projects have time to get done, but there is a mechanism for
doing more short term releases as appropriate ...

> > If you are so bored that you need to organize something, come up with a
> > list of what we hope to accomplish for v7.3 and use that for a guideline
> > for when the beta will start ...
>
> That is a tough one, and something that seems very hard to organize, but
> I can try if you wish.  The TODO list can easily be used for that.
> Another marking stating "Will be done for 7.3" is all it needs.  When
> all the marks are turned to dashes (done) we are ready for beta.

In the future, what should be done, is once we've done the release, take
the "coolling down period" that we alawys have afterwards to generate some
of that list ... a simple post asking who is hoping to accomplish what is
all that is needed ... if they don't speak up and get themselves added to
the list, then what they are workign on is obviously not big enough, or
important enough, to be tied into criteria for beta status ...

> > What major items do ppl have planned for v7.3?  Once those items are
> > completed, then we go into beta for v7.3 and beta lasts until we've gotten
> > her to the point that she's as bug free as she can be without more
> > extensive/broader testing ...
>
> That is a good question and something we do need to ask.  Thanks.
>
> > If those major items are done on the 1st of April, I'll happily declare it
> > the shortest development cycle we've had to date and go beta ... if it
> > takes until the 1st of September, so be it ... but its not going to go
> > beta until its ready, and its not going to be released until its ready ...
> > and setting some arbitrary date is going to do one of two things:  a)
> > pressure developers into making mistakes that will make us look bad, or b)
> > stiffle development while one developer figures "no way I'll get it done
> > by then, so why bother" ...
>
> Agreed, don't release until it is ready, but I think we could make it
> ready faster with some dates.  I am feeling people are doing beta
> testing only near the end of beta because they realize how long it is
> taking.  That is bad.  There is always pressure to lengthen the
> schedule.  I think we need some pressure to shorten it.  That is all I
> am saying.

You can't pressure ppl you aren't paying ... quite frankly, from what I
recall of this past beta, it wasn't testing the code that was a problem,
it was some of the bugs that came up took a bit more then a few minute
fixes ... hell, it says alot when the fix for a beta requests an initdb to
get into the next beta, but we had that here too ...

> > ... and that isn't to throw in the users that are going to say "but you
> > said ... "
>
> Agreed, we certainly want to stay away from that --- users holding us to
> our dates is a recipe for disaster.

As are creating the dates themselves ...

Not sure why you want to change a recipe for development that has worked
for ... what ... 7 years now ... change for the sake of change isn't
necessarily a good idea ...

If you want shorter development times, start making better use of CVS ...
spend the time to back-patch appropriate patches into the REL7_2_STABLE
tree and we can do a release of that every couple of months ... but,
unless I'm mistaken, as we mature more, the enhancements and changes that
are going into each new release is taking longer to implement, with more
far-reaching ramifications, and both *should not* and *can not* be rushed
... I don't know about anyone else, but it doesn't surprise me that beta
testing takes longer then a development cycle anymore ...




Sun, 24 Feb 2002 00:54:32 -0400 (AST)
"Marc G. Fournier" <scrappy@hub.org>
Re: Duration of beta period
> > If you are so bored that you need to organize something, come up with a
> > list of what we hope to accomplish for v7.3 and use that for a guideline
> > for when the beta will start ...
>
> That is a tough one, and something that seems very hard to organize, but
> I can try if you wish.  The TODO list can easily be used for that.
> Another marking stating "Will be done for 7.3" is all it needs.  When
> all the marks are turned to dashes (done) we are ready for beta.

I think that planning a date to go beta is a good thing.  It forces people to 
get their work done before that date, or wait for the next release.  We seem 
to see alot of, "I hope this patch isn't too late for version X".  Defining a 
date to go beta lets people know this ahead of time.  Also, any planned date 
is just that, a plan, not a rule.  Things can /should be moved when / if need 
be.

It might make sense to do something like KDE where developers inform the 
release maintainer of a feature they plan to implement in the upcoming 
version.  This allows the creation of a site that tracks planned features, 
and their status (complete, in progress, not started).  Of course not 
everything would need to be planned ahead of time, but the timing of the beta 
would be based on the planned work.


Sat, 23 Feb 2002 22:57:19 -0600
"Matthew T. O'Connor" <matthew@zeut.net>
Re: Duration of beta period
Marc G. Fournier writes:

> Personally, I think this last beta period was one of our best ones yet ...
> considering the negligible number of bug reports following the release, we
> did exactly what had to be done in teh beta to make sure that the end
> result was as stable as possible for the testing pool we had ...

But it's undeniable that it would be desirable to shorten the beta time.

My feeling during this beta was that a lot of the bugs, porting problems,
etc. could have been caught earlier, that is, before beta, if we had
encouraged more people to run the early snapshots.  In the past, we've
effectively told people, "You're insane if you use development snapshots"
and we've really not revealed at all what the new release was going to be
about until briefly after the start of beta.  Since on average people
aren't going to jump just because we say "beta", it takes weeks or even
months until they bother downloading and testing it, and then they read
the release notes and start questioning decisions made months ago.

The consequence is that during development we're losing thousands of hours
of testing, problems accumulate and get addressed only months later.

I'd say, unless you're actually going into production, it's not
unreasonable to base your project development on snapshots, assuming you
have both a roadmap for the release and a list of changes so far
available.  I've tried to address the second issue with mediocre success,
but the former issue is not to be neglected.

-- 
Peter Eisentraut   peter_e@gmx.net


Sun, 24 Feb 2002 01:10:15 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Re: Duration of beta period
> > It was a good period, but we were in beta longer than we were in
> > development.  That isn't good, and I think we could have shortened it if
> > we had pushed people to test beta sooner and harder, avoided some
> > sideroads in improving things that could have waited for 7.3, and pushed
> > a few people to complete bug fixes quicker than letting it all wait
> > until the end of beta.  Of course, I may be wrong.  :-)
> 
> Where this a commercial product, your assessments would be correct ...
> but, alas, we aren't ... "pushing ppl" that are doing something because
> they enjoy it, and receive no compensation for it, is a very effective way
> of driving good ppl away ...

I see no problem in asking people for a date when they will complete
certain things, especially if everyone is waiting for them during beta. 
If the date comes and nothing happens, we can ask them for a new date. 
If the date is too far away, we can figure on another plan.  I agree
pressure is totally wrong, but asking for an estimate of completion
seems reasonable, and setting a date when we hope to be done may
encourage people to get started earlier.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Sun, 24 Feb 2002 07:51:11 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Duration of beta period
My two cents:

We do need to make the beta period shorter and more focused; and it's
core's responsibility to make that happen by setting the project timeline.

Last fall we had some people still working on new features months after
others had gone into time-for-beta, no-new-features hibernation.  That's
not good; it wastes potential development time to no purpose.  And it's
core's fault for not setting clear expectations for the group (the fact
that there were core members in each camp didn't help un-confuse anyone,
either).  Once we did enter beta, it seemed curiously slow and
unfocused, at least to me.  I think that we got less beta testing than
we have in past cycles, not more --- for example, our failure to learn
that pg_dump was broken for mixed-case database or user names doesn't
speak well to the number of active databases that were migrated.
I suspect that the apparent high quality of the 7.2 release is a matter
of luck, and not a sign of good project management at all.

I believe that both Marc and Bruce have good points here.  As Marc says,
the ultimate bottom line must always be "it's ready when it's ready";
we cannot allow a schedule target to push us into making bad decisions.
But I think Bruce is also correct that we need to have *some* schedule
target, just so that developers can make plans about what features to
work on or leave for a future cycle.  And we need to be more willing
to tell people "you missed the bus for this release"; slipping a
previously-agreed-to release date because noncritical features are still
being worked on is bad project management IMHO.  (BTW, getting back to
a more frequent release cycle would help to make that a more palatable
decision.  If it's four months to the next release, people will be more
willing to wait than if they fear it'll be a year or more.)

As for improving the amount of testing that gets done, maybe we could
advertise the availability of beta releases more widely --- notify
freshmeat, slashdot, etc.

Peter Eisentraut <peter_e@gmx.net> writes:
> My feeling during this beta was that a lot of the bugs, porting problems,
> etc. could have been caught earlier, that is, before beta, if we had
> encouraged more people to run the early snapshots.  In the past, we've
> effectively told people, "You're insane if you use development snapshots"
> and we've really not revealed at all what the new release was going to be
> about until briefly after the start of beta.

True, but we can only improve that if we devote some nontrivial effort
to creating reasonably-trustworthy snapshots.  Right now, no one blinks
an eye if the overnight snapshot is nonfunctional; we fix the problem
and move on.  But how is someone who's not well-tuned-in to know which
nightly snapshots might be safe to use for their own development work?

I think we'd have to make mini-releases, more or less, to attract
testers to use between-releases snapshots.  Maybe that's actually a good
idea, but how will we avoid spending lots of development effort to
coordinate them?

			regards, tom lane

Sun, 24 Feb 2002 10:52:38 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Duration of beta period 
On Sun, 2002-02-24 at 10:52, Tom Lane wrote:
> My two cents:
> 
> We do need to make the beta period shorter and more focused; and it's
> core's responsibility to make that happen....

For my 2 cents, I have access to some 40 redhat machines, and two
running solaris. I can easily test snapshots as RPMs on one of the linux
boxes, but in spite of my best efforts I have not typically had the time
to test solaris, nor is it alway easy to free the resources (though I
will continue to try).

As for Linux, however, the RPMs are typically not available before late
beta. I respectfully suggest that closer intergration of the packaging
would allow more testing. If I can grab the snapshot, and run 'rpm -ta'
to build packages, I can do that with alomost arbitrary frequency. Thus
I could start testing much sooner. I know that would help for me, and I
can't help but think it would help for others as well, whether we're
talking about RPMs or any other packaging method.

It's one thing to as people to run a test. It's another thing still to
ask them to run that test when the only readily available test method
bypasses whatever administrative packaing policy is in place on those
machines.

-- 
Karl DeBisschop <kdebisschop@alert.infoplease.com>
The Learning Network / Reference
www.learningnetwork.com / www.infoplease.com


24 Feb 2002 11:29:36 -0500
Karl DeBisschop <kdebisschop@alert.infoplease.com>
Re: Duration of beta period
Karl DeBisschop writes:

> It's one thing to as people to run a test. It's another thing still to
> ask them to run that test when the only readily available test method
> bypasses whatever administrative packaing policy is in place on those
> machines.

It seems unlikely that many would want to install a development snapshot
as their main installation.

-- 
Peter Eisentraut   peter_e@gmx.net


Sun, 24 Feb 2002 15:39:01 -0500 (EST)
Peter Eisentraut <peter_e@gmx.net>
Re: Duration of beta period
On Sun, 2002-02-24 at 15:39, Peter Eisentraut wrote:
> Karl DeBisschop writes:
> 
> > It's one thing to as people to run a test. It's another thing still to
> > ask them to run that test when the only readily available test method
> > bypasses whatever administrative packaing policy is in place on those
> > machines.
> 
> It seems unlikely that many would want to install a development snapshot
> as their main installation.

Depends what you mean by main installation. I have a few Redhat servers
whose only reason for existing is to test software. So would I want it
to be my main installation for any production-related purpose? No. But
would I want to track PostgreSQL development on that server? Sure, why
not? At least why not if I can use RPM to cleanly remove the software.

Our company policy is that wherever possible, the native package
management tools should be used to install software on a machine,
whether it's a development box or a production server. RPMs are the
native packakging format for Redhat, so we hope to install software
using RPM. I might add, particularly if it's not production software --
since RPM then helps assure that everything that should be removed can
be removed.

Now it is true that I can just install it to part of my home directory,
but that's less than fun over NFS.

And the fact of the matter is, if the goal is to expand testing, which
was what I was trying to comment on, you probably get alot of mileage in
expanding that testing by making packages easy, RPMs, BSD packages,
solaris packages , whatever. It's just a fact that there are people out
there who have little interest in the guts of compilation, but still
have the ability to install and burn in an alpha or beta release.

Again, just my 2 cents.

-- 
Karl DeBisschop <kdebisschop@alert.infoplease.com>
The Learning Network / Reference
www.learningnetwork.com / www.infoplease.com


24 Feb 2002 16:52:15 -0500
Karl DeBisschop <kdebisschop@alert.infoplease.com>
Re: Duration of beta period
Karl DeBisschop <kdebisschop@range.infoplease.com> writes:
> And the fact of the matter is, if the goal is to expand testing, which
> was what I was trying to comment on, you probably get alot of mileage in
> expanding that testing by making packages easy, RPMs, BSD packages,
> solaris packages , whatever.

I agree with Karl on this point --- people who want nonstandard
installations are obviously not going to be able to use such packages,
but it doesn't hurt them any if we provide 'em.  Seems like making
the usual package formats available would garner enough extra
testing to be worth the relatively small effort involved.

Of course, not being one of the people who make up these packages,
that's easy for me to say ;-).  Perhaps I'm wrong in guessing that
the extra effort is small.


This still begs the question of *when* to put out such snapshots.
Picking a reasonable time during the development cycle to capture
a snapshot, and then building derived packages to go with the source
tarball, is looking more and more like a mini-release --- especially
since we'd probably have to attach identifying numbers to the things,
if we want helpful bug reports.  Do we have the energy to do any of
this?  How will we organize it?

			regards, tom lane

Sun, 24 Feb 2002 18:47:34 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Duration of beta period 
On Mon, 2002-02-25 at 05:29, Karl DeBisschop wrote:
> 
> As for Linux, however, the RPMs are typically not available before late
> beta. I respectfully suggest that closer intergration of the packaging
> would allow more testing. If I can grab the snapshot, and run 'rpm -ta'
> to build packages, I can do that with alomost arbitrary frequency. Thus
> I could start testing much sooner. I know that would help for me, and I
> can't help but think it would help for others as well, whether we're
> talking about RPMs or any other packaging method.
> 
> It's one thing to as people to run a test. It's another thing still to
> ask them to run that test when the only readily available test method
> bypasses whatever administrative packaing policy is in place on those
> machines.

Ditto, but for me it is Debian.

I would _really_ like to see basic packaging for RPM and Debian systems
incorporated into CVS / archives so that people like Karl and myself
could more easily build packages to install and test.

These don't have to have all of the bells and whistles of the formal
packages, but I would certainly have been running a beta of 7.2, had
packages been available prior to release.

Regards,
					Andrew.
-- 
--------------------------------------------------------------------
Andrew @ Catalyst .Net.NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/        PHYS: Level 2, 150-154 Willis St
DDI: +64(4)916-7201    MOB: +64(21)635-694    OFFICE: +64(4)499-2267
       Are you enrolled at http://schoolreunions.co.nz/ yet?


25 Feb 2002 13:09:07 +1300
Andrew McMillan <andrew@catalyst.net.nz>
Re: Duration of beta period
On Sunday 24 February 2002 07:09 pm, Andrew McMillan wrote:
> On Mon, 2002-02-25 at 05:29, Karl DeBisschop wrote:
> > As for Linux, however, the RPMs are typically not available before late
> > beta. I respectfully suggest that closer intergration of the packaging
> > would allow more testing. If I can grab the snapshot, and run 'rpm -ta'

> Ditto, but for me it is Debian.

> I would _really_ like to see basic packaging for RPM and Debian systems
> incorporated into CVS / archives so that people like Karl and myself
> could more easily build packages to install and test.

As one of the said packagers, I'm going to drop in my two cents.  

First, the PostgreSQL build isn't terribly RPM/Debian friendly at the moment. 
Now, before Peter E chimes in, let me qualify that comment by saying that 7.2 
is far better than previous releases.

But there are still too many patches, too many releases that won't compile on 
the RPM target systems (beta 4, for instance), and too many idiosyncracies in 
the PostgreSQL RPM build to make it an automatic build at this time.

Now, if I toss the regression tests, maybe that could be done -- or if I, as 
SuSE did for 7.3, integrate the regression testing as part of the build 
instead of an installed package.  But a snapshot RPM definitely would need 
regression test capability -- and the lion's share of the RPM patch is for 
the regression test package.

PostgreSQL has typically been difficult to put in RPM form -- as this 
improves I can see tighter integration possible.

BTW, Karl -- thanks for the initscript patch.

It will be at least two weeks before I can put out another release due to my 
current workload.  If people will feed patches to me, I'll catch up to them 
mid to late March and put out an improved RPM set.  Maybe by then my Red Hat 
6.2-based SPARCclassic will be able to build the RedHat 6.2 compatible source 
RPM's -- and sparc32 binaries, of course.

But, in the meantime, these good suggestions are not falling on deaf ears, 
even if I don't immediately answer this week and next's e-mail.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Sun, 24 Feb 2002 21:18:41 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: Duration of beta period
Just for my own sanity, I agree that using the system packager is a good
idea.  Since I use Slackware, and finding a package for it is usually
difficult (I don't know if pgsql has one), I use checkinstall
(http://asic-linux.com.mx/~izto/checkinstall/)  It creates a system
package based on what 'make install' does. It can create Slackware
packges, RPMs and Debian packages.  Thus I can usually do 'cvs update &&
make && su -c checkinstall' without any probelms (usually because
sometimes you need a distclean/configure in there).  Of course running
out of CVS is probably not much better than the snapshots, but of course
how you get the source is up to you.

--Kevin

Karl DeBisschop wrote:
> 
> On Sun, 2002-02-24 at 15:39, Peter Eisentraut wrote:
> > Karl DeBisschop writes:
> >
> > > It's one thing to as people to run a test. It's another thing still to
> > > ask them to run that test when the only readily available test method
> > > bypasses whatever administrative packaing policy is in place on those
> > > machines.
> >
> > It seems unlikely that many would want to install a development snapshot
> > as their main installation.
> 
> Depends what you mean by main installation. I have a few Redhat servers
> whose only reason for existing is to test software. So would I want it
> to be my main installation for any production-related purpose? No. But
> would I want to track PostgreSQL development on that server? Sure, why
> not? At least why not if I can use RPM to cleanly remove the software.
> 
> Our company policy is that wherever possible, the native package
> management tools should be used to install software on a machine,
> whether it's a development box or a production server. RPMs are the
> native packakging format for Redhat, so we hope to install software
> using RPM. I might add, particularly if it's not production software --
> since RPM then helps assure that everything that should be removed can
> be removed.
> 
> Now it is true that I can just install it to part of my home directory,
> but that's less than fun over NFS.
> 
> And the fact of the matter is, if the goal is to expand testing, which
> was what I was trying to comment on, you probably get alot of mileage in
> expanding that testing by making packages easy, RPMs, BSD packages,
> solaris packages , whatever. It's just a fact that there are people out
> there who have little interest in the guts of compilation, but still
> have the ability to install and burn in an alpha or beta release.
> 
> Again, just my 2 cents.
> 
> --
> Karl DeBisschop <kdebisschop@alert.infoplease.com>
> The Learning Network / Reference
> www.learningnetwork.com / www.infoplease.com
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Mon, 25 Feb 2002 23:54:53 -0500
Kevin <TenToThe8th@yahoo.com>
Re: Duration of beta period