Re: [HACKERS] 8.3 Release Schedule
Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> 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
Re: [HACKERS] 8.3 Release Schedule
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
Re: [HACKERS] 8.3 Release Schedule
Tom Lane wrote: > "Joshua D. Drake" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
Re: [HACKERS] 8.3 Release Schedule
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 <[EMAIL PROTECTED]> 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
Re: [HACKERS] 8.3 Release Schedule
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/ signature.asc Description: This is a digitally signed message part
Re: [HACKERS] 8.3 Release Schedule
"Joshua D. Drake" <[EMAIL PROTECTED]> 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
Re: [HACKERS] 8.3 Release Schedule
Dave Page wrote: --- Original Message --- From: "Joshua D. Drake" <[EMAIL PROTECTED]> To: Bruce Momjian <[EMAIL PROTECTED]> 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
Re: [HACKERS] 8.3 Release Schedule
> --- Original Message --- > From: "Joshua D. Drake" <[EMAIL PROTECTED]> > To: Bruce Momjian <[EMAIL PROTECTED]> > 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. /D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] 8.3 Release Schedule
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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
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. Joshua D. Drake ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match