Re: VS: [HACKERS] Companies Contributing to Open Source

2006-12-20 Thread Joshua D. Drake

> The remainder of this email talks about general principles for all
> developers, not just for company employees.  If we need more text in
> this area, it should be added to the developer's FAQ.  Feel free to
> suggest additions to that.
> 
> I am kind of stumped that we have so much text in the developer's FAQ,
> but it seems many people don't know what is in there.  The Developer's
> FAQ is referenced in the main FAQ, and on the web site.  I am inclinded
> to think that developers know the contents of the developer's FAQ, but
> think they know better, and go ahead and do what they want anyway.  I
> have no idea how to fix that.  :-(

We don't accept patches from anyone who doesn't follow the developer FAQ
rules. Which means of course, that I need to go read it ;)

Sincerely,

Joshua D. Drake




-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate




---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: VS: [HACKERS] Companies Contributing to Open Source

2006-12-20 Thread Bruce Momjian
Heikki Linnakangas wrote:
> Jonah Harris wrote:
> > We could also mention all the Ingres-based offshoots that were
> > commercial.  Let me think of some other examples... but there may not
> > be that many seeing as there aren't really that many PostgreSQL-like
> > communities.  I guess I could mention more if I had a clear
> > understanding of what we mean when we say, "community".
> 
> That's something that bothers me as well: The article and the
> discussions talks about the community, but what's The Community? There
> really isn't any clear definition, the closest thing is the list of
> committers or core members, but I don't think anyone considers The
> Community to be just the committers, though that's the group of people
> whose opinions matter the most when trying to get a patch accepted. I

Not really.  The committers/core just weigh in on the patch, but it is
the general discussion that determines if a patch gets in.  Now, if all
committers don't want a patch, it is unlikely it will be applied, but in
most cases some committers want something, and some don't, and the
discussion determines if it gets in or not, perhaps with modification so
all community members are happy.

The remainder of this email talks about general principles for all
developers, not just for company employees.  If we need more text in
this area, it should be added to the developer's FAQ.  Feel free to
suggest additions to that.

I am kind of stumped that we have so much text in the developer's FAQ,
but it seems many people don't know what is in there.  The Developer's
FAQ is referenced in the main FAQ, and on the web site.  I am inclinded
to think that developers know the contents of the developer's FAQ, but
think they know better, and go ahead and do what they want anyway.  I
have no idea how to fix that.  :-(

---

> don't think it's fruitful to spend time on a precise definition, but
> it's important to realize that there isn't one and that the community
> consists of individuals with different priorities, opinions and points
> of view. Therefore it's a bit meaningless to say that The Community
> thinks this or The Community says that. On one topic, some people might
> have a very strong opinion one way, and others might just not care at
> all. On some topics, everyone agrees. And on some topics, people
> strongly disagree. And that's ok. Respecting all the different
> viewpoints leads to a well-balanced product.
> 
> How does that affect a company trying to get a patch accepted? First,
> do no harm. If you're proposing something that for example brakes
> someone else's application, your proposal is likely to be rejected. Or
> if you're proposing a patch that increases the performance of something,
> at a very high cost on some other things, your patch is likely to be
> rejected. Another kind of harm that many people miss is the
> maintainability of the codebase. Adding complexity for little gain is
> likely to be rejected, just because it'll make the code harder to read.
> 
> Secondly, getting a large feature accepted is easier if you're not just
> dumping a large patch to pgsql-patches, but you're committed to
> maintainting it and developing it further. Remember, some  things you
> might have ignored as not important might be crucial to other people.
> 
> Also, a note to all Members of The Community: people like to work in
> different ways. Some might want to seek acceptance and commitment to
> a feature from others before starting development. Some might want to
> write a large up-front design document before proposing something. Some
> might want to write an experimental patch with a lot of quick hacks
> and no comments, and refine that according to feedback. And we, The
> Members of The Community, if I may count myself as one, don't get to
> choose how others prefer to work.
> 
> --
>  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com

--
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


VS: [HACKERS] Companies Contributing to Open Source

2006-12-20 Thread Heikki Linnakangas
Jonah Harris wrote:
> We could also mention all the Ingres-based offshoots that were
> commercial.  Let me think of some other examples... but there may not
> be that many seeing as there aren't really that many PostgreSQL-like
> communities.  I guess I could mention more if I had a clear
> understanding of what we mean when we say, "community".

That's something that bothers me as well: The article and the discussions talks 
about the community, but what's The Community? There really isn't any clear 
definition, the closest thing is the list of committers or core members, but I 
don't think anyone considers The Community to be just the committers, though 
that's the group of people whose opinions matter the most when trying to get a 
patch accepted. I don't think it's fruitful to spend time on a precise 
definition, but it's important to realize that there isn't one and that the 
community consists of individuals with different priorities, opinions and 
points of view. Therefore it's a bit meaningless to say that The Community 
thinks this or The Community says that. On one topic, some people might have a 
very strong opinion one way, and others might just not care at all. On some 
topics, everyone agrees. And on some topics, people strongly disagree. And 
that's ok. Respecting all the different viewpoints leads to a well-balanced 
product.

How does that affect a company trying to get a patch accepted? First, do no 
harm. If you're proposing something that for example brakes someone else's 
application, your proposal is likely to be rejected. Or if you're proposing a 
patch that increases the performance of something, at a very high cost on some 
other things, your patch is likely to be rejected. Another kind of harm that 
many people miss is the maintainability of the codebase. Adding complexity for 
little gain is likely to be rejected, just because it'll make the code harder 
to read.

Secondly, getting a large feature accepted is easier if you're not just dumping 
a large patch to pgsql-patches, but you're committed to maintainting it and 
developing it further. Remember, some  things you might have ignored as not 
important might be crucial to other people.

Also, a note to all Members of The Community: people like to work in different 
ways. Some might want to seek acceptance and commitment to a feature from 
others before starting development. Some might want to write a large up-front 
design document before proposing something. Some might want to write an 
experimental patch with a lot of quick hacks and no comments, and refine that 
according to feedback. And we, The Members of The Community, if I may count 
myself as one, don't get to choose how others prefer to work.

--
 Heikki Linnakangas
 EnterpriseDB   http://www.enterprisedb.com