8.5 development schedule

[Kevin Grittner]

"Joshua D. Drake" <jd@...> wrote:
> On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
 
>> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
>>  
>> That showed a January 1 beta release and a March 1 production
>> release.
>
> Right that would be the expectation I had.
 
The first of March is still well into the first quarter; but I was
getting confused about beta versus production release schedules when I
said the release was six months late; it was four months late -- to
the day.
 
-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

"Kevin Grittner" <Kevin.Grittner@...> writes:
> Bruce Momjian <bruce@...> wrote:
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year?
 
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> That showed a January 1 beta release and a March 1 production release.

Terminological problem.  Around here, "release" *always* means
production release.  We don't expect end users to be very interested
in pre-production versions.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Kevin Grittner]

Tom Lane <tgl@...> wrote:
> "Kevin Grittner" <Kevin.Grittner@...> writes:
>> That showed a January 1 beta release and a March 1 production
>> release.
>
> Terminological problem.  Around here, "release" *always* means
> production release.  We don't expect end users to be very interested
> in pre-production versions.
 
Well, I actually phrased it with managers here that 8.4 was scheduled
to go to beta on January 1st, but that the actual release date was
less predictable because the PostgreSQL community worries more about
having a solid release than hitting a release date.  Based on
discussions on the hackers list, I actually had the impression that
there would be a concerted effort to hit the beta date.
 
But, yeah -- on this thread I got the dates confused a bit.  I'm happy
to see that the slippage was less severe than I had got myself
thinking it was.  A third of a year, rather than half.
 
-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Kevin Grittner wrote:

> "Joshua D. Drake" <jd@...> wrote:
> > On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:
>  
> >> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
> >>  
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> >
> > Right that would be the expectation I had.
>  
> The first of March is still well into the first quarter; but I was
> getting confused about beta versus production release schedules when I
> said the release was six months late; it was four months late -- to
> the day.

OK, that is more accurate, but looking at the schedule:

        1st November 2008 - final commit fest begins
        1st January 2009 - beta 1
        1st March 2009 - 8.4.0 release

How could we have possibly completed the last commit-fest and gotten
ready for beta in two months --- that is just not realistic.  I think we
anticipated a 2x longer final commit-fest, two months, but there was no
time scheduled for actual beta preparation.  I think there was some
ideal that we wouldn't need any time to prepare for beta and that we
would have dealt with all bugs by the time the last commit-fest is
complete, but that is illusory.

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Kevin Grittner wrote:

> Tom Lane <tgl@...> wrote:
> > "Kevin Grittner" <Kevin.Grittner@...> writes:
> >> That showed a January 1 beta release and a March 1 production
> >> release.
> >
> > Terminological problem.  Around here, "release" *always* means
> > production release.  We don't expect end users to be very interested
> > in pre-production versions.
>  
> Well, I actually phrased it with managers here that 8.4 was scheduled
> to go to beta on January 1st, but that the actual release date was
> less predictable because the PostgreSQL community worries more about
> having a solid release than hitting a release date.  Based on
> discussions on the hackers list, I actually had the impression that
> there would be a concerted effort to hit the beta date.
>  
> But, yeah -- on this thread I got the dates confused a bit.  I'm happy
> to see that the slippage was less severe than I had got myself
> thinking it was.  A third of a year, rather than half.

And I have just posted that a lack of scheduled time for beta
preparation was one reason for the slippage.

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Ron Mayer]

Bruce Momjian wrote:
> Where did you see 8.4 was scheduled to be released around the start of
> the year?  I never never seen that and would have disputed anyone saying
> it publicly.

I think people carefully avoided the word "scheduled", but the
press FAQ on www.postgresql.org did say to expect it in Q4 08.


http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
http://www.postgresql.org/about/press/faq
   Q: When will 8.4 come out?
   A: Historically, PostgreSQL has released approximately
      every 12 months and there is no desire in the community
      to change from that pattern. So expect 8.4 sometime in
      the fourth quarter of 2008.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

Bruce Momjian <bruce@...> writes:
> OK, that is more accurate, but looking at the schedule:

> 1st November 2008 - final commit fest begins
> 1st January 2009 - beta 1
> 1st March 2009 - 8.4.0 release

> How could we have possibly completed the last commit-fest and gotten
> ready for beta in two months --- that is just not realistic.

We didn't know that at the time, though.  We thought the last CF would
take a month plus.  And up till November the CFs *were* getting done
in about a month.

In retrospect, the CF idea took some of the edge off the problem of
lots of large patches arriving at the feature freeze deadline, but it
is far from having eliminated the problem.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Ron Mayer wrote:

> Bruce Momjian wrote:
> > Where did you see 8.4 was scheduled to be released around the start of
> > the year?  I never never seen that and would have disputed anyone saying
> > it publicly.
>
> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.postgresql.org did say to expect it in Q4 08.
>
>
> http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
> http://www.postgresql.org/about/press/faq
>    Q: When will 8.4 come out?
>    A: Historically, PostgreSQL has released approximately
>       every 12 months and there is no desire in the community
>       to change from that pattern. So expect 8.4 sometime in
>       the fourth quarter of 2008.

OK, now that someone has brought it up --- I have been disappointed with
the anticipated release dates we broadcast to the press --- without
community approval or oversight.  This is not the first time, but
hopefully it is the last.

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Kevin Grittner]

Bruce Momjian <bruce@...> wrote:
 
> How could we have possibly completed the last commit-fest and gotten
> ready for beta in two months --- that is just not realistic.  I
> think we anticipated a 2x longer final commit-fest, two months, but
> there was no time scheduled for actual beta preparation.
 
For my edification, could you point me at something which identifies
the work needed after everything is committed and before the first
beta is released?  (I can't remember reading anything like that, but
it may have fallen through the cracks.)
 
If no such page exists, could you sketch out a brief outline?
 
> I think there was some ideal that we wouldn't need any time to
> prepare for beta and that we would have dealt with all bugs by the
> time the last commit-fest is complete, but that is illusory.
 
I thought one of the purposes of the two-month beta testing phase on
the calendar was to find and fix bugs.  That was in addition to the
two month final commit-fest.
 
-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

Ron Mayer <rm_pg@...> writes:
> Bruce Momjian wrote:
>> Where did you see 8.4 was scheduled to be released around the start of
>> the year?  I never never seen that and would have disputed anyone saying
>> it publicly.

> I think people carefully avoided the word "scheduled", but the
> press FAQ on www.postgresql.org did say to expect it in Q4 08.

> http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php
> http://www.postgresql.org/about/press/faq
>    Q: When will 8.4 come out?
>    A: Historically, PostgreSQL has released approximately
>       every 12 months and there is no desire in the community
>       to change from that pattern. So expect 8.4 sometime in
>       the fourth quarter of 2008.

Whoever wrote that certainly didn't ask any of the core hackers about
the phrasing.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Tom Lane wrote:

> Bruce Momjian <bruce@...> writes:
> > OK, that is more accurate, but looking at the schedule:
>
> > 1st November 2008 - final commit fest begins
> > 1st January 2009 - beta 1
> > 1st March 2009 - 8.4.0 release
>
> > How could we have possibly completed the last commit-fest and gotten
> > ready for beta in two months --- that is just not realistic.
>
> We didn't know that at the time, though.  We thought the last CF would
> take a month plus.  And up till November the CFs *were* getting done
> in about a month.
>
> In retrospect, the CF idea took some of the edge off the problem of
> lots of large patches arriving at the feature freeze deadline, but it
> is far from having eliminated the problem.

The beta preparation is dealing with all open issues, which is different
than the focus of the commit-fest.  Ideally we would be addressing those
open/bug issues during normal development, but for the hard problems
seem to linger and then we have to deal with them during beta
preparation, which can take 1-2 months.

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

Bruce Momjian <bruce@...> writes:
> Tom Lane wrote:
>> In retrospect, the CF idea took some of the edge off the problem of
>> lots of large patches arriving at the feature freeze deadline, but it
>> is far from having eliminated the problem.

> The beta preparation is dealing with all open issues, which is different
> than the focus of the commit-fest.  Ideally we would be addressing those
> open/bug issues during normal development, but for the hard problems
> seem to linger and then we have to deal with them during beta
> preparation, which can take 1-2 months.

We've never scheduled a "beta preparation" phase like that before,
and I don't recall you complaining about the lack of one in the 8.4
schedule.  Personally I think the slip is entirely due to the final
CF taking five months (we closed it 25-March) where we'd expected
something closer to one month.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Kevin Grittner wrote:

> Bruce Momjian <bruce@...> wrote:
>  
> > How could we have possibly completed the last commit-fest and gotten
> > ready for beta in two months --- that is just not realistic.  I
> > think we anticipated a 2x longer final commit-fest, two months, but
> > there was no time scheduled for actual beta preparation.
>  
> For my edification, could you point me at something which identifies
> the work needed after everything is committed and before the first
> beta is released?  (I can't remember reading anything like that, but
> it may have fallen through the cracks.)
>  
> If no such page exists, could you sketch out a brief outline?

I just posted on this, but the answer is that commit-fest is for getting
patches applied --- it does not address open bugs that have to be
addressed before we can go to beta.  Those bugs could be new or could be
related to previously-applied patches.  That process can take 1-2
months.

>  
> > I think there was some ideal that we wouldn't need any time to
> > prepare for beta and that we would have dealt with all bugs by the
> > time the last commit-fest is complete, but that is illusory.
>  
> I thought one of the purposes of the two-month beta testing phase on
> the calendar was to find and fix bugs.  That was in addition to the
> two month final commit-fest.

But usually by the time we finish the last commit-fest, we already have
lots of bugs we know about (usually hard to fix), and it doesn't make
sense to go into beta with known bugs.

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Tom Lane wrote:

> Bruce Momjian <bruce@...> writes:
> > Tom Lane wrote:
> >> In retrospect, the CF idea took some of the edge off the problem of
> >> lots of large patches arriving at the feature freeze deadline, but it
> >> is far from having eliminated the problem.
>
> > The beta preparation is dealing with all open issues, which is different
> > than the focus of the commit-fest.  Ideally we would be addressing those
> > open/bug issues during normal development, but for the hard problems
> > seem to linger and then we have to deal with them during beta
> > preparation, which can take 1-2 months.
>
> We've never scheduled a "beta preparation" phase like that before,
> and I don't recall you complaining about the lack of one in the 8.4
> schedule.  Personally I think the slip is entirely due to the final
> CF taking five months (we closed it 25-March) where we'd expected
> something closer to one month.

I didn't bring it up because the schedule was kind of a first attempt
and it didn't make sense to try and tune it at that point.

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Kevin Grittner]

Bruce Momjian <bruce@...> wrote:
> The beta preparation is dealing with all open issues, which is
> different than the focus of the commit-fest.  Ideally we would be
> addressing those open/bug issues during normal development, but for
> the hard problems seem to linger and then we have to deal with them
> during beta preparation, which can take 1-2 months.
 
Is there any way to move some of that work up into the earlier commit
fests?  (I'm afraid I still don't have my head around exactly what
sorts of issues are addressed in this phase.)
 
By the way, I hope that nobody is taking any of my observations or
questions as criticism or complaint.  It seems pretty obvious that the
process currently involves a fair amount of frustration and pain for
all involved, and I'm trying to brainstorm to help.  Don't think for a
minute that I forget or fail to appreciate the tremendous work you do,
along with that done by everyone else.
 
-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Kevin Grittner wrote:

> Bruce Momjian <bruce@...> wrote:
> > The beta preparation is dealing with all open issues, which is
> > different than the focus of the commit-fest.  Ideally we would be
> > addressing those open/bug issues during normal development, but for
> > the hard problems seem to linger and then we have to deal with them
> > during beta preparation, which can take 1-2 months.
>  
> Is there any way to move some of that work up into the earlier commit
> fests?  (I'm afraid I still don't have my head around exactly what
> sorts of issues are addressed in this phase.)

Basically when someone reports a bug against CVS HEAD we try to fix it
but if the fix is complex, we usually just leave it for later, hence the
beta preparation time.  I think we assume some ideal fix will occur to
us but once we are near beta, we have no more time so we fix it as best
we can.

> By the way, I hope that nobody is taking any of my observations or
> questions as criticism or complaint.  It seems pretty obvious that the
> process currently involves a fair amount of frustration and pain for
> all involved, and I'm trying to brainstorm to help.  Don't think for a
> minute that I forget or fail to appreciate the tremendous work you do,
> along with that done by everyone else.

We understand your motivation.

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

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

Bruce Momjian <bruce@...> writes:
> Kevin Grittner wrote:
>> However, even the *possibility* that this could be true is pretty
>> scary.  If we need to effectively shut down new development for seven
>> months at the end of a release, in addition to the interim commit
>> fests, we'd better get a handle on why, so that can change.  To what
>> do you attribute the extended time needed to handle the final CF?
>> How can that be made better?

> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close the
> final commit-fest.  To be clear I am talking about patches that were
> eventually applied in 8.4, not patches that were rejected for 8.4.

I think this is simply not in agreement with the facts.  The patches
that caused the greatest amount of delay for 8.4 were the ones that
ultimately got rejected --- notably hot standby, sync rep, and
sepostgres.  Now the fact that everybody knew they would take awhile
provided some "cover" for other patches that weren't quite ready.
If we had bounced those three on Nov. 1 the commit fest would've been
a lot shorter.  Probably some other things that did get in would've
gotten bounced too, but on the whole I think the project would have been
better off.

The long and the short of it is that there is always tremendous pressure
to include patches that are on the edge of being ready, because we all
know that bouncing them to the next release cycle will mean an extra
year before they're available in production.  The dynamic in 8.4 was
exactly the same as it's been in the prior release cycles: we keep
slipping the possible release date and trying to get those patches
ready, and we don't give up until everyone agrees the release is just
hopelessly late.  As long as we keep behaving that way, no amount of
schedule-setting or rule-making is going to change anything.

It comes down to somebody having the willingness to say "no" and the
authority to make it stick.  Robert mentioned upthread that the
committers don't want to be seen as throwing their weight around,
which is quite true, but I have also noticed in the past that saying
"no" does not convince whoever is arguing that "this release will suck
if it doesn't have this feature".  And there's always somebody arguing
that side --- usually several people.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Joshua D. Drake]

On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:

> It comes down to somebody having the willingness to say "no" and the
> authority to make it stick.  Robert mentioned upthread that the
> committers don't want to be seen as throwing their weight around,

Is that the purpose of core? To make exactly those decisions?

Sincerely,

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@...
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

"Joshua D. Drake" <jd@...> writes:
> On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
>> It comes down to somebody having the willingness to say "no" and the
>> authority to make it stick.  Robert mentioned upthread that the
>> committers don't want to be seen as throwing their weight around,

> Is that the purpose of core? To make exactly those decisions?

Core has never seen itself as intended to make feature-by-feature
decisions.  People seem to be willing to defer to us on release
schedule-setting, but it's not clear to me that the community has
delegated us more authority than that.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Joshua D. Drake]

On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote:

> "Joshua D. Drake" <jd@...> writes:
> > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote:
> >> It comes down to somebody having the willingness to say "no" and the
> >> authority to make it stick.  Robert mentioned upthread that the
> >> committers don't want to be seen as throwing their weight around,
>
> > Is that the purpose of core? To make exactly those decisions?
>
> Core has never seen itself as intended to make feature-by-feature
> decisions.  People seem to be willing to defer to us on release
> schedule-setting, but it's not clear to me that the community has
> delegated us more authority than that.

I would agree that having core decide on specific features is probably a
stretch but having core set a cut date to which *all* patches that don't
make that date? That seems within purview.

Sincerely,

Joshua D. Drake
 

--
PostgreSQL - XMPP: jdrake@...
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers