Re: damage control mode

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: damage control mode
Дата
Msg-id 603c8f071001091112k648f1ec6yeb94cfc64848ab2c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: damage control mode  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: damage control mode
Список pgsql-hackers
On Sat, Jan 9, 2010 at 9:33 AM, Peter Eisentraut <peter_e@gmx.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.

Specifics?

> 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.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Re: CVS HEAD: Error accessing system column from plpgsql trigger function
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: maintenance announcement for dekeni.postgresql.org and minshara.postgresql.org