On Thu, 27 Aug 2009, Ron Mayer wrote:
> The Linux kernel seems to do fine with a "when it is ready" cycle,
> where some releases(2.6.24) take twice the time of others(2.6.28)[1,2].
> [2] http://fblinux.freebase.com/view/base/fblinux/views/linux_kernel_release
That link has bad data. If you check the tagging dates by looking at the
source material here:
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.27
http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.28
You can see that 2.6.28 didn't come out until 2008-12-14, not the
2008-10-24 claimed on the freebase.com site.
> I imagine it has similar stability and lack-of-data-loss requirements
> as postgres does.
The Linux kernel developers are very clear that they don't care one bit
about testing for stability or lack of data loss in any system-oriented
way. That's somebody else's job now, typically the Linux distributor who
decides which of the kernels floating around are the most stable,
hopefully running more and larger tests than the kernel developers do.
For example, if you consider Ubuntu 9.04 Jaunty, development started with
2.6.27, upgraded to 2.6.28, then rejected moving to 2.6.29 even though
they might have slipped it in.[1] When faced with the similar decision for
2.6.26 vs. 2.6.27 in the previous release, they went for the later one,
based on the features they needed to be stable.[2] 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.
[1] http://www.h-online.com/news/No-2-6-29-kernel-for-Jaunty-Jackalope--/112636
[2] https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026142.html
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
