Re: knngist patch support - Mailing list pgsql-hackers

From tomas@tuxteam.de
Subject Re: knngist patch support
Date
Msg-id 20100211213925.GA17972@tomas
Whole thread Raw
In response to Re: knngist patch support  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Feb 11, 2010 at 03:19:14PM +0100, Dimitri Fontaine wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > It seems that you're sort of frustrated with the system and the need
> > to go through a process before committing a patch; 
> 
> I've been handling arround here for years (since 2005 or before) and I
> think there always was a process. The only change is it's getting more
> and more formal. But still not any clearer.

I didn't want to give the impression that I see the process as too
heavy. Granted, knngist is a cool feature, and I'm a big fan of Oleg and
Teodor (since they pulled the hstore trick :)

Still I think Robert is doing a terrific job. The weight of the big
patches has increased considerably in the last years, and without the
heroic efforts of some people (adn Robert is definitely among them!),
PostgreSQL's release process wouldn't have been as smooth.

> It's good to try to keep the major releases one year apart, but until
> now we had some flexibility towards developpers. They could have their
> own agenda then appear with a big patch and it was getting considered.
> 
> We never asked contributors to arrange for being able to find a
> sponsor, do the closed source version, prepare for publishing, and then
> send a patch in a timely maneer so that to ease the integration and
> release. 
> 
> Before there was a Commit Fest process, we took some weeks then months
> at the end of the cycle to consider what had been accumulated.

Yes. But remember HOT. Things seem smoother nowadays (disclaimer: I'm
just a bystander).

> The new process is there for giving more feedback to developpers, and is
> being considered now as a way to get better control about the release
> agenda. I'm not sure it's a good tool for that. I'm not sure insisting
> that much on the release schedule is a good idea.

What's your proposal then? Allow more slippage in the release schedule?
How much? When?

> Once more making compromises is easy. What's hard and challenging is
> making *good* compromises.

Agreed

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLdHkNBcgs9XrR2kYRAhSsAJ4n899St+aPYkRA7XBX78vF/xZh9wCfZ3T0
h226KRarnFrEEIcOY+zBG9E=
=X9fa
-----END PGP SIGNATURE-----


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: review: More frame options in window functions
Next
From: Bart Samwel
Date:
Subject: Re: Hostnames in pg_hba.conf