On Fri, Aug 28, 2009 at 7:35 AM, Greg Smith<gsmith@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