On Fri, Aug 28, 2009 at 7:35 AM, Greg Smith<gsm...@gregsmith.com> wrote: > It's really amazing that a useful result ever comes out of this model at > all, and I know I'm not alone that I presume all Linux kernel releases are > too full of bugs to be useful until I've proven otherwise with my own QA. > > If the core PostgreSQL development worked like the Linux kernel, at the end > of each CommitFest whatever was done at that point would get published as > the new release. Instead of pausing to focus on a stable release everyone > would just speed ahead, backporting any major issues not discovered until > after the official release.
The lesson that they took from earlier releases was that "pausing" development just led to heartache and delays and didn't actually help the release at all. Keep in mind that the Linux kernel itself is just an integration effort now anyways. All the actual development happens in other trees earlier anyways. Patches are only sent up to Linux when they've been fully developed (and hopefully somewhat tested) elsewhere. The arguments against the Linux approach are that a) it involves a lot of backpatching which is a pain. This is less convincing than it appears because the more often you fork branches the less different they all are. b) Our developers are also our testers and we don't have independent distribution vendors available to do testing. Actually we do, aside from people like EDB who have large test suites we're discussing how to get more testing from users precisely because our developers aren't really our testers. The big difference between Linux and ourselves is that it's a lot more work to migrate a database. So nobody would be particularly helped by having frequent releases. It would make a lot of sense even for us when the day comes that most people just run whatever Redhat or Debian ship. In which case we could come out with releases but users would happily ignore those releases until Redhat or Debian picked out, tested it, and released it in their distributions. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
