2010/1/7 Magnus Hagander <magnus@hagander.net>:
> 2010/1/7 Devrim GÜNDÜZ <devrim@gunduz.org>:
>> On Thu, 2010-01-07 at 11:55 -0500, Robert Haas wrote:
>>
>>> Personally, I would rather have a release without SR in June or July
>>> than a release with SR in August or September.
>
> June, yes. July, frankly, no, because July == September, when it comes
> to any such scheduling. At least in the countries where my clients are
> :)
In terms of when the release comes out, maybe. In terms of the NEXT
release, it still matters. If the release is delayed, the first
CommitFest of the next release will be that much later. If we put out
a release by July 1 of this year, we can repeat the same schedule for
the next release that we are using for this release and I will be
happy with that. If we don't put out a release until September, our
first CommitFest will be at least 2 months later than it was for the
last one, which means that (1) we will have a gap of 8 months without
a CommitFest and (2) 8.6 will have no chance of coming out before
September 2011, and may end up being more like Thanksgiving if that
one also slips.
I really don't want to go 8 months with no CommitFest. That leads to
too many patches in the queue, too many merge conflicts, too many
patch authors who just plain give up, and no feedback to anyone for a
very, very long time.
>> If SR will be ready until then, I'd like to see a release in September
>> which has SR in it. We already postponed SR a lot. Many of advocacy
>> people including me already mentioned about SR, and many people are
>> lookig after it. BTW, July probably won't be a good time for a new
>> release, because of people's holidays.
>
> -1. Frankly, if advocacy people said it would be there, they didn't
> tell the truth, and that's their problem. If they said "hopefully it
> will be there, but we don't know yet", then they don't have a problem
> either way.
>
> Not having our release schedule driven by marketing is a *strength* of
> our project!
>
> We made the mistake last time to delay the release significantly for a
> single feature. It turned out said feature didn't make it *anyway*.
> Let's not repeat that mistake.
Indeed.
...Robert