Re: Where to load modules from?

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Where to load modules from?
Date: 2013-09-15 23:54:39
Message-ID: 523648BF.4020501@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 09/15/2013 05:52 PM, Jeff Janes wrote:
> On Sun, Sep 15, 2013 at 6:51 AM, Peter Eisentraut <peter_e(at)gmx(dot)net
> <mailto:peter_e(at)gmx(dot)net>> wrote:
>
> On Sat, 2013-09-14 at 22:15 +0200, Dimitri Fontaine wrote:
> >
> > This proposal comes with no patch because I think we are able to
> > understand it without that, so that it would only be a waste of
> > everybody's time to attach code for a random solution on the
> list here
> > to that email.
>
> It shouldn't be in the commit fest if it has no patch.
>
>
> I thought the general recommendation was the opposite, that planning
> and road maps should be submitted for review before non-trivial coding
> is started; and that despite the name the commitfest is the best way
> that this is done. Of course now I can't find the hackers thread where
> this recommendation was made...
>
>

It is unquestionably correct that roadmaps and planning should be made
available for review and discussion. But the assertion that this should
be done via the commitfest is not. The commitfest app has never been for
anything other than code, that I am aware of, and I am quite sure you
will find fierce resistance to any notion that design discussions should
take place anywhere but on this mailing list.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2013-09-16 00:05:09 Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Re: [HACKERS] Is it necessary to rewrite table while increasing the scale of datatype numeric?
Previous Message Noah Misch 2013-09-15 23:49:26 Re: record identical operator