Thread: Duration of beta period
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, Pennsylvania19026
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 ... "
> 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, Pennsylvania19026
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 ...
> > 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.
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
> > 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, Pennsylvania19026
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
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
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
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
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
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?
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
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