Thread: 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 betterat 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 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 thinkgoing forward we'll need to resign ourselves to the fact that this is going to keep happening, and plan on spendingmore 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. Aprilfreeze, Aug-Sept beta, Oct release. /D
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.
Ithink going forward we'll need to resign ourselves to the fact that this is going to keep happening, and plan on
spendingmore 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.
Aprilfreeze, 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