8.5 development schedule

[Bruce Momjian-5]

Joshua D. Drake wrote:

> 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.

Define "make that date"?  That is the problem.

--
  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

[Andrew Dunstan]

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.
>
>
>  

You have correctly identified the requirement in the sentence quoted
above. I for one am quite prepared to support core or some person
designated by core having such authority. I agree with you that without
something like that not much will improve.

cheers

andrew

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

[Robert Haas]

On Wed, Jul 1, 2009 at 5:01 PM, Tom Lane<tgl@...> wrote:

> 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

This is also how I remember it.

> 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.

It wasn't just the big patches that dragged on forever: for example,
updateable views got submitted literally hours before the start of the
CommitFest in a state where it did not even pass regression tests, I
reviewed it, there was a loooong delay before resubmit, then it got
committed, then it got reverted.  If we had ejected that patch from
the queue (for non-resubmission, if nothing else) early on in the
process, it would have freed up at least three people's time (Tom's,
mine, Peter's) to work on other patches that were in better shape and
submitted sooner.

One of the WORST mistakes that we made with the November CommitFest
was to only assign reviewers to the small patches, figuring that the
committers would look at the big ones.  SE-PostgreSQL was not given a
reasonable review for a very long time.  What we need to do this time
is start with the biggest patches and assign the most capable
reviewers (committers, preferably) to those patches and then work down
the list.  This is another example of the uncomfortable dynamic
between committers and everyone else: non-committers don't feel
comfortable assigning committers to review patches, because who are we
to tell the commiters what to do?  But when the committers are the
only ones competent to do that review, the result is a huge vacuum.
We need to put some structure around this that works.

I do agree, however, that rejecting more patches sooner (in
particular, the ones that had been reviewed and found wanting) would
have been the way to go and good for the project.

> 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.

Yep.

> 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.

Yep.  But having a review that clearly enumerates the reasons WHY the
patch needs to be rejected is certainly more compelling than a blanket
statement that the patch is big and invasive and therefore must have
bugs, even if we haven't looked at it enough to find them.  The
blanket statement may be quite true, but it doesn't provide feedback
to the patch author and so fails to accomplish one of the main
purposes of the CommitFests, at least IMO.

...Robert

--
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:
 
> Define "make that date"?  That is the problem.
 
Not committed by that date.  I guess that leaves the issue of picking
a particular time in a particular time zone, but it doesn't otherwise
seem ambiguous.
 
Picture the New York Subway system.  You're coming down the stairs and
the train is in sight.  You either make it through the doors before
they close, or you don't.  If you don't, you wait for the next train.
The system would never work if they held up the train for everyone in
sight of the train who hoped to get on to avoid the wait.  Nobody is
throwing their weight around when those doors close; it's just how the
system works.
 
-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:
>  
> > Define "make that date"?  That is the problem.
>  
> Not committed by that date.  I guess that leaves the issue of picking
> a particular time in a particular time zone, but it doesn't otherwise
> seem ambiguous.
>  
> Picture the New York Subway system.  You're coming down the stairs and
> the train is in sight.  You either make it through the doors before
> they close, or you don't.  If you don't, you wait for the next train.
> The system would never work if they held up the train for everyone in
> sight of the train who hoped to get on to avoid the wait.  Nobody is
> throwing their weight around when those doors close; it's just how the
> system works.

The problem is that the committers control the commit date, but the one
seen as punished for a rejected patch is not the committers but the
submitter.

--
  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

[Greg Stark-5]

On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane<tgl@...> wrote:

> I'm also not prepared to push a large and unstable feature into the tree
> on the hope that it will get fixed.

I didn't have the impression it had any known problems, Simon and
others spent a lot of time testing it already. The improvements Heikki
was asking for were simplifications or cleanup type changes and every
time he asked for something Simon had it done within a day or two.

The problem is I think this will *always* be a "large unstable
feature" just because it's large. If we aren't happy having it in the
tree for alpha releases then there's no circumstance we'll ever be
happy having it in a real release. I think it's a *lot* better having
it in the alpha releases when if we find problems we can revert it or
fix the problems than dropping it at the last second before the betas
when it has to be perfect and there's no second chances.

--
greg
http://mit.edu/~gsstark/resume.pdf

--
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 problem is that the committers control the commit date, but the
> one seen as punished for a rejected patch is not the committers but
> the submitter.
 
Well, it would seem odd for anyone to feel "punished".
 
If the patch isn't submitted in good form with the issues hashed out
in prior discussion, and the reviewer(s) and committer(s) can't
resolve the issues prior to the cutoff -- well, try to address those
issues for the next release.  Maybe submit with a bit more lead time
next time around.
 
As is often pointed out here, nothing stops you from using your own
patch if you need to.  We did so here, for example, with the standard
character string literals.  Had that patch never been accepted, we'd
still be patching new releases.  I'm sure that's not always an option,
but I'll bet it often is.
 
If the submitter is anxious to make a particular release, they should
be motivated to submit early, turn around quickly, and raise a fuss if
the patch seems to be wanting for attention.
 
One possible solution would be to have trains leaving the station more
often.  I know that the idea of more frequent releases has been
proposed and rejected before, but that option is sort of screaming to
be considered again in all of this.  Are the mentions of alpha
releases a way to edge into this area -- a feature which misses a
major release could be available to the intrepid within a month or
two, should it then be finished and committed, in a semi-formal way?
 
-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]

bruce wrote:
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I can
> think of, they were not rejected immediately _because_ we had other
> valid patches to work on.  Once all valid patches were applied, we were
> quickly able to reject the large unready patches.
>
> So, rejecting the large patches early would not have significantly
> moved the release date earlier.

I see no one agrees with my analysis --- no matter;  if I unreservedly
agreed with others, I wouldn't be here.  ;-)

There has been discussion about how to be more hard-nosed about
rejecting patches.  I think it has to start with us being more
hard-nosed about giving patches feedback --- the very idea we had to
create commit-fests reflects that we historically have not done an
organized job of processing patches.

If we review patches as soon as they appear, and give rapid feedback, we
can easily reject patches that take more than a few days for the patch
author to resolve, and there would be little slippage;  the same goes
for dealing with known bugs.  I know it can be done, but I don't promise
it would be pleasant.

--
  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]

Greg Stark wrote:

> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane<tgl@...> wrote:
>
> > I'm also not prepared to push a large and unstable feature into the tree
> > on the hope that it will get fixed.
>
> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it already. The improvements Heikki
> was asking for were simplifications or cleanup type changes and every
> time he asked for something Simon had it done within a day or two.
>
> The problem is I think this will *always* be a "large unstable
> feature" just because it's large. If we aren't happy having it in the
> tree for alpha releases then there's no circumstance we'll ever be
> happy having it in a real release. I think it's a *lot* better having
> it in the alpha releases when if we find problems we can revert it or
> fix the problems than dropping it at the last second before the betas
> when it has to be perfect and there's no second chances.

By that logic we would never have accepted large patches, but we have,
often.

--
  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]

Greg Stark <gsstark@...> writes:
> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane<tgl@...> wrote:
>> I'm also not prepared to push a large and unstable feature into the tree
>> on the hope that it will get fixed.

> I didn't have the impression it had any known problems, Simon and
> others spent a lot of time testing it already.

If it didn't have known problems it would have been committed in 8.4.

                        regards, tom lane

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

[Robert Haas]

On Wed, Jul 1, 2009 at 6:53 PM, Kevin
Grittner<Kevin.Grittner@...> wrote:
> Bruce Momjian <bruce@...> wrote:
>
>> The problem is that the committers control the commit date, but the
>> one seen as punished for a rejected patch is not the committers but
>> the submitter.
>
> Well, it would seem odd for anyone to feel "punished".

Depends on who the patch submitter thinks is at fault.  Sometimes,
patches legitimately don't get reviewed as much as would be good.
Other times, the submitter just thinks the committer is nitpicking.  I
think Bruce summarized it pretty well.

Really, when you get right down to it, you can guarantee that all
patches get a certain amount of review, or you can guarantee that the
CommitFest ends by a certain date, but not both, because you can't
force other people to spend more time on PostgreSQL than they have to
spend.  At best, you can get them to spend the time that they do have
on the right sort of things (e.g. reviewing rather than developing new
patches during CommitFest).

Of course, since you want both of those things to happen, it's a balancing act.

...Robert

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

[Robert Haas]

On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjian<bruce@...> wrote:

> bruce wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I can
>> think of, they were not rejected immediately _because_ we had other
>> valid patches to work on.  Once all valid patches were applied, we were
>> quickly able to reject the large unready patches.
>>
>> So, rejecting the large patches early would not have significantly
>> moved the release date earlier.
>
> I see no one agrees with my analysis --- no matter;  if I unreservedly
> agreed with others, I wouldn't be here.  ;-)
>
> There has been discussion about how to be more hard-nosed about
> rejecting patches.  I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> organized job of processing patches.

Agreed.

> If we review patches as soon as they appear, and give rapid feedback, we
> can easily reject patches that take more than a few days for the patch
> author to resolve, and there would be little slippage;  the same goes
> for dealing with known bugs.  I know it can be done, but I don't promise
> it would be pleasant.

Also agreed.  It's never pleasant to have a patch rejected/postponed,
but it's tolerable if you've gotten some feedback and understand the
reasons why.  Of course there is no guarantee that you will agree with
those reasons, but that's life.  Some day you may be the committer and
have your turn to irritate patch submitters.  :-)

...Robert

--
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:
> There has been discussion about how to be more hard-nosed about
> rejecting patches.  I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> organized job of processing patches.

> If we review patches as soon as they appear, and give rapid feedback, we
> can easily reject patches that take more than a few days for the patch
> author to resolve, and there would be little slippage;  the same goes
> for dealing with known bugs.  I know it can be done, but I don't promise
> it would be pleasant.

In other words, you propose dropping the idea of commitfests, and
expecting committers to spend *all* their time reviewing?  Tain't
happening.

                        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]

Robert Haas wrote:

> > If we review patches as soon as they appear, and give rapid feedback, we
> > can easily reject patches that take more than a few days for the patch
> > author to resolve, and there would be little slippage; ?the same goes
> > for dealing with known bugs. ?I know it can be done, but I don't promise
> > it would be pleasant.
>
> Also agreed.  It's never pleasant to have a patch rejected/postponed,
> but it's tolerable if you've gotten some feedback and understand the
> reasons why.  Of course there is no guarantee that you will agree with
> those reasons, but that's life.  Some day you may be the committer and
> have your turn to irritate patch submitters.  :-)

Our only limitation is our own sense that we have been fair to patch
authors, i.e. there is no external restriction on how we handle things.

--
  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:
> > There has been discussion about how to be more hard-nosed about
> > rejecting patches.  I think it has to start with us being more
> > hard-nosed about giving patches feedback --- the very idea we had to
> > create commit-fests reflects that we historically have not done an
> > organized job of processing patches.
>
> > If we review patches as soon as they appear, and give rapid feedback, we
> > can easily reject patches that take more than a few days for the patch
> > author to resolve, and there would be little slippage;  the same goes
> > for dealing with known bugs.  I know it can be done, but I don't promise
> > it would be pleasant.
>
> In other words, you propose dropping the idea of commitfests, and
> expecting committers to spend *all* their time reviewing?  Tain't
> happening.

"I don't promise it would be pleasant."

--
  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

[Robert Haas]

On Wed, Jul 1, 2009 at 7:00 PM, Tom Lane<tgl@...> wrote:
> Greg Stark <gsstark@...> writes:
>> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane<tgl@...> wrote:
>>> I'm also not prepared to push a large and unstable feature into the tree
>>> on the hope that it will get fixed.
>
>> I didn't have the impression it had any known problems, Simon and
>> others spent a lot of time testing it already.
>
> If it didn't have known problems it would have been committed in 8.4.

What I've seen of Heikki's work thus far has led me to believe that
his reasons for rejecting the patch were good ones, but I don't
specifically what they were.  It would be helpful, I think, to
reiterate them or repost links to the relevant messages in the
archives; it would also be great if we could get an estimate of how
close the patch is to being committable.  Does it still need massive
work, or is it getting fairly close, or what?  Are the issues code
cleanliness/maintainability, bugs, missing functionality?

From our conversations at the PGcon development meeting it seems as
though there are a lot of people for whom this is a high-priority
feature.  Perhaps some of them will be willing to help if we give them
enough information to work with.

...Robert

--
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:
>> Bruce Momjian <bruce@...> writes:
>>> If we review patches as soon as they appear, and give rapid feedback, we
>>> can easily reject patches that take more than a few days for the patch
>>> author to resolve, and there would be little slippage;  the same goes
>>> for dealing with known bugs.  I know it can be done, but I don't promise
>>> it would be pleasant.
>>
>> In other words, you propose dropping the idea of commitfests, and
>> expecting committers to spend *all* their time reviewing?  Tain't
>> happening.

> "I don't promise it would be pleasant."

I'm not sure which part of "no" you didn't understand, but this
committer is not buying into that proposal.

                        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:
> > Tom Lane wrote:
> >> Bruce Momjian <bruce@...> writes:
> >>> If we review patches as soon as they appear, and give rapid feedback, we
> >>> can easily reject patches that take more than a few days for the patch
> >>> author to resolve, and there would be little slippage;  the same goes
> >>> for dealing with known bugs.  I know it can be done, but I don't promise
> >>> it would be pleasant.
> >>
> >> In other words, you propose dropping the idea of commitfests, and
> >> expecting committers to spend *all* their time reviewing?  Tain't
> >> happening.
>
> > "I don't promise it would be pleasant."
>
> I'm not sure which part of "no" you didn't understand, but this
> committer is not buying into that proposal.

Again, I am pointing out it could be done, but it would be unpleasant,
as you mentioned.  We can't move make progress unless we understand the
underlying causes of our delays.  I am not suggesting we adopt it for
reasons you mentioned.

--
  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

[Stefan Kaltenbrunner]

Tom Lane wrote:

> 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.

Thtat change was done as part of the website changes for the 8.3 release
which we usually get through Josh(who is usually creating the
presskits).The relevant commit message would be:
https://pgweb.postgresql.org/changeset/1888.


Stefan

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

[Guillaume Smet-3]

On Wed, Jul 1, 2009 at 11:42 PM, Andrew Dunstan<andrew@...> wrote:
> You have correctly identified the requirement in the sentence quoted above.
> I for one am quite prepared to support core or some person designated by
> core having such authority. I agree with you that without something like
> that not much will improve.

That's the role of a release manager. Perhaps it's time to think about
designating one for each release to endorse this responsability.

--
Guillaume

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