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(at)gmx(dot)net
In response to
pgsql-hackers by date
|Next:||From: Karl DeBisschop||Date: 2002-02-24 12:42:12|
|Subject: Re: elog() proposal|
|Previous:||From: Matthew T. O'Connor||Date: 2002-02-24 04:57:19|
|Subject: Re: Duration of beta period|