8.3 Release Schedule
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, or discard patches to force an earlier beta. The idea of
discarding patches is bad for two reasons:
1) It is not fair to the patch submitters who completed their
work by the feature freeze.
2) We are going to be no better at dealing with these patches
during 8.4 than we are now.
While someone could make the case that we need to disregard #1 for the
good of the community release, #2 is really a firm issue we can't
ignore. So, unless we can say we don't want the functionality in the
pending patches we have to just keep moving forward.
All outstanding patches are probably things we want so there is no value
to pushing them to 8.4. In fact, some of these we pushed from 8.2 to
8.3, and as you can see, they got little major review during the 8.3
development cycle, so now is the time to give them the attention they
need.
On the patch status page:
http://developer.postgresql.org/index.php/Todo:PatchStatus
We have three major patches:
* HOT
* Group Item Tuples
* Text Search
With six weeks left until the start of September, I think we can assume
four weeks to focus on these three big patches, then another few weeks
to apply the more minor patches and resolve all outstanding issues
before we enter beta.
The good news is that 8.3 is going to be a blockbuster release. 8.2 was
the polishing of existing features so it is good 8.3 is going to be a
_must-upgrade_ release for most users.
In fact, one of the reasons that it is taking so long to get to beta is
that thanks to development from EnterpriseDB and others we are getting
8.4 and 8.5 features in 8.3. But those features are coming from people
who don't have a history of developing complex patches for PostgreSQL so
we have to be extra-careful in review. Assuming the review goes well,
we can assume that less review will be required for future patches from
these developers so hopefully 8.4 will be quicker.
--
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. +
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.
Joshua D. Drake
Joshua D. Drake wrote:
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.
When we set the date, we didn't know those patches were going to be
finished in time.
--
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. +
------- 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 ScheduleBruce 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.
/D
Import Notes
Resolved by subject fallback
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 ScheduleBruce 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/
"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
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/
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. +
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. +
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
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