<quote> "Companies often bring fresh prespective, ideas, and testing infrastucture to a project." </quote>
"prespective" || "perspective" ? g.- On 12/21/06, Kevin Grittner <[EMAIL PROTECTED]> wrote:
>>> On Tue, Dec 19, 2006 at 6:13 PM, in message <[EMAIL PROTECTED]>, Bruce Momjian <[EMAIL PROTECTED]> wrote: > if the company dies, the community keeps going (as it did after Great > Bridge, without a hickup), but if the community dies, the company dies > too. This statement seems to ignore organizations for which PostgreSQL is an implementation detail in their current environment. While we appreciate PostgreSQL and are likely to try to make an occasional contribution, where it seems to be mutually beneficial, the Wisconsin State Courts would survive the collapse of the PostgreSQL community. While I can only guess at the reasons you may have put the slant you did on the document, I think it really should reflect the patient assistance the community provides to those who read the developers FAQ and make a good faith effort to comply with what is outlined there. The cooperative, professional, and helpful demeanor of the members of this community is something which should balanced against the community's need to act as a gatekeeper on submissions. I have recent experience as a first time employee contributor. When we hit a bump in our initial use of PostgreSQL because of the non-standard character string literals, you were gracious in accepting our quick patch as being possibly of some value in the implementation of the related TODO item. You were then helpful in our effort to do a proper implementation of the TODO item which fixes it. I see that the patch I submitted was improved by someone before it made the release, which is great. This illustrates how the process can work. I informed management of the problem, and presented the options -- we could do our own little hack that we then had to maintain and apply as the versions moved along, or we could try to do fix which the community would accept and have that feature "just work" for us for all subsequent releases. The latter was a little more time up front, but resulted in a better quality product for us, and less work in the long term. It was also presumably of some benefit to the community, which has indirect benefit to our organization. Nobody here wants to switch database products again soon, so if we can solve our problem in a way that helps the product gain momentum, all the better. I ran a consulting business for decades, and I know that there is a great variation in the attitudes among managers. Many are quite reasonable. I'm reminded of a meeting early in my career with a businessman who owned and operated half a dozen successful businesses in a variety of areas. He proposed a deal that I was on the verge of accepting, albeit somewhat reluctantly. He stopped me and told me that he hoped to continue to do business with me, so any deal we made had to benefit and work for both of us or it was no good at all; if I was uncomfortable with something in the proposal, we should talk it out. That's the core of what we're trying to say in this document, isn't it? The rest is an executive overview of the developer FAQ? I can't help feeling that even with the revisions so far it could have a more positive "spin". -Kevin ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
-- Guido Barosio ----------------------- http://www.globant.com [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
