Dave Page wrote:
>
>> ------- Original Message -------
>> From: "Joshua D. Drake" <jd@commandprompt.com>
>> To: Bruce Momjian <bruce@momjian.us>
>> Sent: 19/07/07, 19:27:04
>> Subject: Re: [HACKERS] 8.3 Release Schedule
>>
>> Bruce Momjian wrote:
>>> I have been thinking about where we are in the release process for 8.3.
>>>
>>> I know we hoped for a July beta, but soon after the 8.3 feature freeze
>>> it was clear that we weren't going to make that date. I am sure some
>>> people are frustrated we are not closer to beta.
>>>
>>> Looking at where we are now, there are only two alternatives --- keep
>>> pressing on,
>> +1
>>
>> The reality is, we have several *large* patches that have come in over
>> this development cycle. I don't know that we expected that when we tried
>> to do the short cycle release.
>
> I agree - I certainly didn't expect so many large patches when I put the idea of a short cycle to the rest of -core. I think going forward we'll need to resign ourselves to the fact that this is going to keep happening, and plan on spending more time in freeze next time round.
>
> Actually thinking about it, I think we should plan the next cycle based on whatever ends up happening this time - eg. April freeze, Aug-Sept beta, Oct release.

I actually would be more inclined to have an even shorter cycle release
next time... e.g. January Freeze. The original idea was sound, make it
so we aren't testing in the middle of summer.

Joshua D. Drake

>
> /D
>


--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

"Joshua D. Drake" <jd@commandprompt.com> writes:
> Dave Page wrote:
>> Actually thinking about it, I think we should plan the next cycle
>> based on whatever ends up happening this time - eg. April freeze,
>> Aug-Sept beta, Oct release.

> I actually would be more inclined to have an even shorter cycle release
> next time... e.g. January Freeze. The original idea was sound, make it
> so we aren't testing in the middle of summer.

I think part of the problem is exactly that the freeze period has
stretched into summer, and so people aren't around for one reason or
another, and so it's going slower than one could wish.

As already noted, when we set the schedule we were not expecting to have
so many large patches dropped on us at the very end of the devel cycle.
What I'd like to think about is how can we avoid *that* happening again?
Maybe there's no way, because human nature is to not finish stuff much
before the deadline :-(. But dealing with a big patch logjam is
obviously overwhelming the community's resources.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Hi,

On Thu, 2007-07-19 at 16:47 -0400, Tom Lane wrote:
> As already noted, when we set the schedule we were not expecting to
> have so many large patches dropped on us at the very end of the devel
> cycle. What I'd like to think about is how can we avoid *that*
> happening again?

I think we can set a "Feature proposal" deadline, which is 2-3 months
before "feature freeze" deadline... If someone pushes the proposal and
it is accepted, he/she can begin coding until feature freeze...

Regards,

--
Devrim GÃœNDÃœZ
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBGn9Nfpme12CBXnxERAp65AKCdIxw3WNutYCQmnvCvd4 IFXu0XPQCgiyyi
oAPrAvi/q+UTkxRiiHpFaKc=
=/VPO
-----END PGP SIGNATURE-----

Devrim GÜNDÜZ wrote:
-- Start of PGP signed section.
> Hi,
>
> On Thu, 2007-07-19 at 16:47 -0400, Tom Lane wrote:
> > As already noted, when we set the schedule we were not expecting to
> > have so many large patches dropped on us at the very end of the devel
> > cycle. What I'd like to think about is how can we avoid *that*
> > happening again?
>
> I think we can set a "Feature proposal" deadline, which is 2-3 months
> before "feature freeze" deadline... If someone pushes the proposal and
> it is accepted, he/she can begin coding until feature freeze...

We had a 1-month window this time for that.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > Dave Page wrote:
> >> Actually thinking about it, I think we should plan the next cycle
> >> based on whatever ends up happening this time - eg. April freeze,
> >> Aug-Sept beta, Oct release.
>
> > I actually would be more inclined to have an even shorter cycle release
> > next time... e.g. January Freeze. The original idea was sound, make it
> > so we aren't testing in the middle of summer.
>
> I think part of the problem is exactly that the freeze period has
> stretched into summer, and so people aren't around for one reason or
> another, and so it's going slower than one could wish.
>
> As already noted, when we set the schedule we were not expecting to have
> so many large patches dropped on us at the very end of the devel cycle.
> What I'd like to think about is how can we avoid *that* happening again?
> Maybe there's no way, because human nature is to not finish stuff much
> before the deadline :-(. But dealing with a big patch logjam is
> obviously overwhelming the community's resources.

I am not sure the dump of patches at the end was the cause, particularly
because we are approaching the time where we are spending more time in
feature freeze than in development. I think the larger problem is that
these patches are just hard to review.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

All,

> > I think part of the problem is exactly that the freeze period has
> > stretched into summer, and so people aren't around for one reason or
> > another, and so it's going slower than one could wish.

So, push feature freeze up to Feb 1. That would give us 2-3 months of review
before "summer" starts, and would help. It would also make it more probable
that we can release in time for a major OSS conference for a big announcement
(yeah, wearing my marketing hat again. It's my assigned role).

> I am not sure the dump of patches at the end was the cause, particularly
> because we are approaching the time where we are spending more time in
> feature freeze than in development. I think the larger problem is that
> these patches are just hard to review.

Actually, knowing what people are working on, I expect the issue to get
*worse* with each release -- Gavin's Windowing Functions, for example, or if
I get 2-3 Sun engineers working full time on SMP scalability (it's possible).
I do still think we should consider a distributed VCS so that at least bitrot
isn't part of the equation for review logjam.

Overall, I think we should start planning for a 3-4 month integration period
as a normal fact of life.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Tom Lane wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> Dave Page wrote:
>>> Actually thinking about it, I think we should plan the next cycle
>>> based on whatever ends up happening this time - eg. April freeze,
>>> Aug-Sept beta, Oct release.
>
>> I actually would be more inclined to have an even shorter cycle release
>> next time... e.g. January Freeze. The original idea was sound, make it
>> so we aren't testing in the middle of summer.
>
> I think part of the problem is exactly that the freeze period has
> stretched into summer, and so people aren't around for one reason or
> another, and so it's going slower than one could wish.
>
> As already noted, when we set the schedule we were not expecting to have
> so many large patches dropped on us at the very end of the devel cycle.
> What I'd like to think about is how can we avoid *that* happening again?
> Maybe there's no way, because human nature is to not finish stuff much
> before the deadline :-(. But dealing with a big patch logjam is
> obviously overwhelming the community's resources.

I'm confident we can address that over time. It's easy for companies
like NTT and EDB to start flooding us with big patches, but it takes
time for us to start to trust their developers enough that 'regular'
reviewers/committers can rely on them. We're already getting extremely
high quality reviews from people like Heikki and over coming cycles I
hope we'll get to trust more of the new flock of contributors who in
turn will help relieve some of the workload.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq