Skip site navigation (1) Skip section navigation (2)

Re: damage control mode

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, David Fetter <david(at)fetter(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: damage control mode
Date: 2010-01-09 19:12:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Sat, Jan 9, 2010 at 9:33 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On fre, 2010-01-08 at 21:01 -0500, Robert Haas wrote:
>> > The commitfest is a tool for people to track what is going on, not a
>> > tool to tell people what to do.
>> I don't understand what you mean by this.  Can you please elaborate?
> The proposal was apparently that a small, vocal group gets to decide
> what features are more important than others, and then change the commit
> fest listing to make everyone work on those features instead of some
> other ones.

I'm sorry it came across that way.  That wasn't my intention.  I am
afraid that I may have taken Tom's suggestion more seriously than it
was meant, or more seriously than I should have.  I have been spending
a very large amount of time on PostgreSQL lately for reasons that are
OT for this list, and most of that work has been directed toward
trying to make it possible for us to release on time.  I'm afraid that
I may have let myself get a little too wrapped up in this.  If there
is not a community consensus toward making an on-time release
possible, then it is not a good idea for me to devote as much time as
I have been to helping us get there, because (1) it won't work and (2)
I'll be frustrated when it doesn't.

>> And I thought we had agreement that one of
>> those ground rules was "don't submit new, large patches to the final
>> CommitFest in a particular release cycle".  No?
> I don't agree with that

If we accept large patches at the very end of the development cycle,
that's when people will submit them.  You've previously criticized the
high proportion of the release cycle that is set aside for CommitFest
and beta, so I'm surprised to see you advocating for a policy that
seems likely to lengthen the time for which the tree is closed.

> or the way it was assessed in this case.


> The reason why I make these points is that if you make the commit fest
> too selective, then, since you are not the employer of anyone, people
> who don't agree with your choices will just ignore them and do something
> else.

Individual contributors can do whatever they like, and they do.  We
have a number of committers, such as yourself, who could be very
helpful in getting us to release sooner, with more features, or both.
However, so far, Tom Lane is the only committer who has indicated any
willingness or time to work on any of these large patches, and so when
we say we don't want to bump any patches, are we really saying we just
want Tom to fit them into his schedule?  Some people, such as Dimitri,
have opined that we should go ahead and do first-level review of all
of them, and I'm fine with that.  But as far as committer review for
those large patches, we don't seem to have a better plan than hoping
Tom can work it all in.  And he may be able to do that, but he's
clearly said he doesn't think HS is ready for beta, so then beta will
be later.


In response to


pgsql-hackers by date

Next:From: Dean RasheedDate: 2010-01-09 19:34:30
Subject: Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function
Previous:From: Stefan KaltenbrunnerDate: 2010-01-09 19:12:21
Subject: maintenance announcement for and

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group