Re: 8.5 release timetable, again
От | Greg Smith |
---|---|
Тема | Re: 8.5 release timetable, again |
Дата | |
Msg-id | alpine.GSO.2.01.0908280203450.13559@westnet.com обсуждение исходный текст |
Ответ на | Re: 8.5 release timetable, again (Ron Mayer <rm_pg@cheapcomplexdevices.com>) |
Ответы |
Re: 8.5 release timetable, again
Re: 8.5 release timetable, again |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: