Why is PostgreSQL getting dramatically more patches?
…the volume of patches [to PostgreSQL] has risen dramatically during the past few years.
This is total hearsay — I don’t have hard numbers, haven’t verified it myself, etc etc. But consider the source!
What can be responsible for this increase in patches to PostgreSQL?
Well ever since 8.0, PostgreSQL has been gaining speed in their
development. I think EnterpriseDB is partly responsible for this. But I
think its also the increase in transparency in their development process
that is to be “blamed”. A while ago they started a wiki, which at the
beginning was heavily disputed. I worked with several people on recording
planned features etc. This quickly grew to add RFC-style pages for the
planning of new features, quick documentation of new features etc. Today the
wiki has gotten its new home at a more prominent location
(http://wiki.postgresql.org/wiki/Main_Page) due to its success.
Furthermore they have dared to look into improving their overall process of
how patches are reviewed and accepted. In the past patches fell of new
releases just because nobody was able to review the patch before feature
freeze. This of course not only means delayed features, its also a major
contribution turn off. Their most recent innovation is the CommitFest idea
(http://wiki.postgresql.org/wiki/CommitFest), where they dedidcated
mulltiple intervals at regular times during the development (way before
feature freeeze time) for patch reviewing. That being said, I have stopped
reading the hackers list about a year ago, so I am not as much in tune with
the PostgreSQL community as I was 2 years ago. However I am very excited
with what these guys are going.
Lukas
23 May 08 at 8:28 am
Lukas, I couldn’t agree with you more. :)
Things that need to change to get MySQL contributions increased:
* Determine whether to use the SCA
* Get onto bzr and off of bitkeeper
* Open up the roadmap for community additions (I am working on this now…)
* Use Launchpad for community trees, with full commit access to appropriate community contributors
* Stop our release policies which detriment the community server
Jay Pipes
23 May 08 at 11:19 am
Jay,
Doesn’t using Launchpad sort of stick you right back into a similar situation as exists with bitkeeper? Is there another reason that I don’t know of why you recommend getting off bitkeeper, besides that it isn’t Free Software? I know that a lot of Free Software advocates are not happy about LP being non-free. There is some push to make it free, but I don’t think that Canonical has any plans to do so, or at least I am unaware of any (no surprise since I’m not very informed about these things).
I’m just wondering, and I’ll happily listen to your response.
Nathaniel
3 Jun 08 at 8:29 pm
Nathaniel,
The free (as in beer) version of BK doesn’t have even basic functionality such as merge and diff, so it’s really a non-starter for getting true contributions from the community. Even though LP is non-free, it’s built on top of open, full featured FOSS products, and is fully functional.
-jay
Jay Pipes
4 Jun 08 at 10:03 am