Re: damage control mode

On Sat, Jan 9, 2010 at 8:07 AM, Dimitri Fontaine <dfontaine(at)hi-media(dot)com> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>  I have always
>> felt that the purpose of a CommitFest was to give everyone a fair
>> shake at getting their patch reviewed, provided that they followed
>> certain ground rules.
>
> Yes, like for example submitting the patch before the commit fest
> begins.

Right.

>> 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 remember this having been agreed upon.

As far as I know we have always had this rule. Here is Tom talking
about having it for 8.4 and trying to formalize it for 8.5.

http://archives.postgresql.org/pgsql-hackers/2009-06/msg01520.php

Here is Josh discussing the details of how the rule should be
implemented, while agreeing that it exists:

http://archives.postgresql.org/pgsql-hackers/2009-09/msg00141.php

There are also various messages in the archives where various patch
authors discuss development plans they have made to avoid running
afoul of this rule.

Basically, here's my feeling. Either we have a rule that we can
bounce large, previously-unseen patches from the final CommitFest of
the release cycle, or we don't. If we do, then we should go ahead and
do it, and we should do it early when it will have more effect rather
than putting a lot of time into those patches and doing it only once
the release is already late. On the other hand, if we don't, then we
should have to core team publish a clear statement that all
CommitFests are equal and we're just going to slip the schedule if
there are too many patches for the last one.

Right now, what we have is some patch authors (like Jeff Davis)
holding off from submitting big new features to the last CommitFest,
essentially voluntarily, and others (like KaiGai Kohei, and I think
perhaps also Simon Riggs) making Herculean attempts to meet certain
deadlines even when they seemed somewhat artificial. Then on the flip
side we have others like Teodor and Oleg who submitted large patches
at the end of the development cycle. Of course, Teodor and Oleg are
free to do their development whenever they like, but why should we
review their work and not Jeff's? It seems to me that having a rule
and not enforcing it is the worst of all possible worlds: it
essentially punishes people who have voluntarily followed it.

From a practical standpoint, it seems much better to me to have the
rule than not, because committing large patches earlier in the cycle
seems better from the point of view of having them well-tested and
stabilized before the release comes out. But if the consensus is that
we have no such rule, then let's be honest about it.

> What I think have been
> said before is that doing so would not help stabilizing the tree before
> release.

Sorry, I'm not following this sentence.

> You seem to be wanting to put a lot of energy into being successful at
> following the current release schedule, which others seem to be seeing
> as an hint or a wish more than anything else (it's the expected one, not
> the one we're committed to, I'd venture).
>
> Is it more important to follow the calendar or to be unable to know with
> a month precision when we're going to release the best possible 8.5?
> Again, it's a compromise to find. You're pushing towards the calendar,
> we're advocating staying fair (opened?) with contributors even when it
> means we're taking risks on the schedule.

I am definitely pushing for the schedule. It's a maxim of software
development that you can have time-based releases or feature-based
releases, but not both. In this community, we have time-based
releases early in the cycle and then they change to feature-based
releases late in the cycle. As we found out with 8.4, trying to be
both on time and feature-complete can result in failing at both. I
feel that we've been eminently fair to contributors in the 8.5 cycle -
it's something that I have personally worked very hard on - and I
actually also feel that what I am proposing now is also fair. It may
not be very popular, though.

...Robert