Folks, > (And how do we decide what's the best interest of the project as a > whole, anyway? Well, community consensus is the only way that I can > see. Again, the critical factor is that no one voice drown out the > rest.)
Well, a lot of it has been about the core committee and trust. The rest of us trust the core committee to promote what they think is best for PostgreSQL, and not what their employers think, unless the two are compatible (for example, I don't think anyone objects to SRA's pushing Windows ... ). Plus most of the core committee is very active on the mailing lists and actively fields user requests and answers user opinions. So if one of us gets mad that a feature or patch was turned down, nobody is left with the opinion that it's becuase the core committee wasn't paying attention or is speaking for their employers. Nor would any every expect that we would see a feature that had been rejected for the TODO list suddenly appear in the source tree. If private companies using their own money want to change the *priorities* on the TODO list, that's fine -- and no different from volunteer programmers with an itch to scratch, except maybe in scale. Besides, I think most of us active participants have some business related to Postgres. I'm a consultant, for example, and I freely admit that I pushed for not waiting for Win32 and PITR for 7.4 because some of my clients want to use 7.4 now and not later, with or without those features. Sometimes the process breaks down a bit ... I can think of a few features which were discussed and accepted on the Hackers list and then rejected when they reached Patches ... but the vast majority of the time it works better than the projects I know with a larger community and a more formal governance structure. If it ain't broke, don't fix it. -- Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
