Re: small but useful patches for text search

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: small but useful patches for text search
Date: 2009-03-16 21:15:08
Message-ID: B6713EB5-882D-4BC0-89AC-86AC5ED2C357@hi-media.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Le 16 mars 09 à 21:41, Tom Lane a écrit :
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> I think it's clear that stretching feature freezes is a failed
>> policy.
>
> A saner policy would mandate that large patches land near the start of
> a development cycle, but I don't know how we get people to do that.

I think Open Source showed that you can't have both time based
releases and feature based releases. Anytime any project try to
accomodate those two objectives, they fail at both.

It seems that PostgreSQL is leaning towards time based releases, which
I think made up the majority in our community. What I'd propose is to
refuse new patches posted in last two commit fests. Those are reserved
to bake what we release.

I'm not sure that's the best compromise you can do, even if it's
definitely one, but it has the merit to be quite clear and easy to
understand for contributors: you want your code to appear in X.Y, get
it reviewed at least once (with feedbacks) before we enter the last
but one commitfest. If you fail at this, you get to (try to) have your
code in X.Y+1, which won't be released that far away (about 1 year
away from a known date).

Regards,
--
dim

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-03-16 21:22:58 Re: Problem with accesing Oracle from plperlu functionwhen using remote pg client.
Previous Message Heikki Linnakangas 2009-03-16 21:10:49 Re: small but useful patches for text search