Re: Support for QNX6, POSIX IPC and PTHREAD-style locking
От | Igor Kovalenko |
---|---|
Тема | Re: Support for QNX6, POSIX IPC and PTHREAD-style locking |
Дата | |
Msg-id | 01b101c17782$0f098320$2001acc0@c773082g обсуждение исходный текст |
Ответ на | Re: Support for QNX6, POSIX IPC and PTHREAD-style locking (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Support for QNX6, POSIX IPC and PTHREAD-style locking
|
Список | pgsql-patches |
----- Original Message ----- From: "Ross J. Reedstrom" <reedstrm@rice.edu> To: "Igor Kovalenko" <Igor.Kovalenko@motorola.com> Cc: <pgsql-patches@postgresql.org> Sent: Tuesday, November 27, 2001 9:21 AM Subject: Re: [PATCHES] Support for QNX6, POSIX IPC and PTHREAD-style locking > On Mon, Nov 26, 2001 at 09:39:42PM -0600, Igor Kovalenko wrote: > > > > > Exceptions are > > > always made, but a new feature has never qualified for such an exception. > > > > > > "There will always be another release." > > > > Sure. I think I made it clear enough why I want it in 7.2. I also took away > > the most interesting part of patch since there were some valid logical > > objections against including it as is. I thought that would clear the way, > > but now I am presented with unbeatable 'this is untested' reason. Who do you > > think would be testing it if it was included in 7.3 or 8.0 for that matter? > > Not you, I suspect. That would be same old me probably and why do you think > > few weeks of testing by me and my fellows then will be somehow better than > > same testing we've done now? > > Because if it _does_ break other peoples builds, it'll happen in an > unstable devlopment tree, which constitutes testing, and everyone just > says 'hmm, fix that'. If it gets in now, there's a chance it'll break > someone's build _no matter how much you've tested it_. If that happens > in a _stable release_, now we have a problem. PostgreSQL has a strong > track record of no 'brown paper bag' bugs in stable releases (well, > almost none). You seldom see a minor version number over 3 or 4, for > that reason. Logically 'proving' that your patch _couldn't possibly_ > cause any problems has no impact on the matter: there are stranger build > environments out there than you've dreamed of, and someone has ported > PostgreSQL to most of them. Gotta love this argument. If what you're saying has any real ground, it just means Postgres source structure and build process sucks beyond anything I've seen before. It SHOULD BE possible to logically prove that addition of new platform does not break others. If not, you've got yourself problem without my patch. > At this point, I'd suggest you yield gracefully: the core developers > don't want it right now, but have read your patch and given you valuable > feedback, to improve you submission for 7.3 (in about two weeks). <bow><bow><bow> At this point, I suggest core developers will ask me when/if they feel like they want another submission from me. <bow><bow><bow> Merry X-mas & happy new year everyone. <yield><yield><yield> - igor
В списке pgsql-patches по дате отправления: