8.5 development schedule

[Tom Lane-2]

"Joshua D. Drake" <jd@...> writes:
> We already push and pull our release dates based are what in the queue,
> we just do so informally. Why not just make it part of the process? That
> way we are being up front and saying, "Yeah, we have no idea. We will
> review in 6 months and that is when we decide our target."

I think we used to do it more or less like that, but people didn't like
it because they couldn't do any long-range planning.

                        regards, tom lane

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

[Tom Lane-2]

Robert Haas <robertmhaas@...> writes:
> I agree.  On the other hand, I think all of the proposed schedules are
> somewhat optimistic about how long the final release will take.  We
> started the final CommitFest for 8.4 on November 1st and are set to
> release July 1st.  The proposed schedule for next time involves
> starting the final CommitFest three months later and releasing two
> months earlier.  I'd like to think that with a little more discipline
> around CommitFests we can tighten things up a little, but it seems
> excessively optimistic to think that we're going to cut down from
> seven months to two.

Yeah.  What I think the 8.4 cycle taught us is that commitfests are a
good thing but they won't magically eliminate the need to say "no" at
the end.  If we are willing to be sufficiently hardnosed about saying
"no", we can make the final commitfest short.  Otherwise it's going to
drag on just like this one did.

Keeping the final-CF-to-release period short is desirable for the
reasons already mentioned --- we don't want to shut down development
for a long period.  So even if it's optimistic, I think we should
write the schedule that way.  We can be certain that the period won't
last *less* time than scheduled :-(

> I would propose to start CommitFests July 15th, September 15th,
> November 15th, and January 15th, planning all but the last to be one
> month long.  The last CommitFest I would plan on closing up by March
> 1st, with release hopefully by June 1st.

Hmm.  If we drop the notion that CFs have to start on month boundaries,
that's actually not a bad schedule --- in particular, it keeps us away
from expecting much of anything to get done in the last half of
December.  I'd suggest setting the target release date to May 15
(pre-PGCon), as long as we're working with ides-of-whichever dates.

> As for thresholds, I'd propose that we measure the size of patches
> using "diff -u | diffstat".  If the number of insertions plus the
> number of deletions is >= 1000, then the patch is not eligible for the
> final CommitFest unless it was submitted for the penultimate
> CommitFest.  This obvious discriminates against patches with a large
> footprint that are not very invasive and in favor of those with a
> small footprint that are more destabilizing, but it's a clean line in
> the sand, and I think having such a line is better than trying to
> apply human judgment to every case.

Well, in the end it will come down to committers' judgements anyway;
if someone thinks a patch is ready it will probably go in, regardless
of size.  But this gives us another tool for saying "no", so I'm
agreeable ;-)

                        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:
 
> I think we used to do it more or less like that, but people
> didn't like it because they couldn't do any long-range planning.
 
Well, obviously the 8.4 release cycle did little to help them.
 
As has already been observed, there is a crying need to say "no" at
some point to get a release out.
 
It might actually help to do that on big patches if we don't let too
many tiny ones accumulate.  I seem to remember the argument being tossed
about that "we might as well keep working on this one because there's
all these others to wrap up."
 
-Kevin


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

[Heikki Linnakangas-3]

Robert Haas wrote:
> In any case, we probably need some weigh-in from Heikki and Simon on
> their plans for Hot Standby before we make any decisions...

I'm planning to spend considerable amount of time reviewing and helping
with hot standby and synchronous replication, but someone else will have
to take the lead.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

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

[Heikki Linnakangas-3]

Merlin Moncure wrote:
> Given that there is also a lot of work on synchronous replication, is
> it better to get the HS in so the SR stuff can use that as a baseline,
> or to triage in both patches together?

Whichever finishes first. Although they're very useful together, there
is little if any code-level dependency between them. It would be
dangerous to have one wait for the other, as one or the other could well
be delayed for some reason. We can't even be sure that both are finished
in time for 8.5.

--
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

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

[Alvaro Herrera-7]

Kevin Grittner wrote:

> It might actually help to do that on big patches if we don't let too
> many tiny ones accumulate.  I seem to remember the argument being tossed
> about that "we might as well keep working on this one because there's
> all these others to wrap up."

Yeah, and the people who was able to work on the small patches was too
busy helping on the bigger items.

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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

[Josh Berkus]

> I would propose to start CommitFests July 15th, September 15th,
> November 15th, and January 15th, planning all but the last to be one
> month long.  The last CommitFest I would plan on closing up by March
> 1st, with release hopefully by June 1st.

This sounds good to me.  Anyone object?

> As for thresholds, I'd propose that we measure the size of patches
> using "diff -u | diffstat".  If the number of insertions plus the
> number of deletions is>= 1000, then the patch is not eligible for the
> final CommitFest unless it was submitted for the penultimate
> CommitFest.  This obvious discriminates against patches with a large
> footprint that are not very invasive and in favor of those with a
> small footprint that are more destabilizing, but it's a clean line in
> the sand, and I think having such a line is better than trying to
> apply human judgment to every case.

I think we need human judgement.  You could easily make a 4-line change
to a macro or one of the planner files which would require endless
debugging.

The deciding people on "big patches" for the final commitfest should be
a combination of the commitfest managers and the core team.  And we
should weed out the disqualified before January 15.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

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

[Josh Berkus]

On 6/29/09 10:33 PM, Peter Eisentraut wrote:

> Now that 8.4.0 is out the door, development for 8.5devel will be opened any
> day now.  But we haven't discussed the development timeline so far.  The core
> team has several proposals:
>
> CommitFest      Alpha
> Aug. 1          Sept. 1
> Oct. 1          Nov. 1
> Dec. 1          Jan ~~ 5
> Feb. 1          March 4
>
> Release ~ May 2010
>
> This puts us on track for a release at the same time next year, maybe a little
> earlier.

One thing Peter forgot to mention here is that the next-to-last
commitfest is the *last* commitfest for new major features.  For the
*last* commitfest, any patch introduced either has to be a resubmission
of something we've seen at a prior CF, or has to be very "small" (i.e.
not many lines/files, no side effects, no API or defined standard API).

This makes the next-to-last CF our "biggest" CF.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

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

[Tom Lane-2]

Josh Berkus <josh@...> writes:
>> I would propose to start CommitFests July 15th, September 15th,
>> November 15th, and January 15th, planning all but the last to be one
>> month long.  The last CommitFest I would plan on closing up by March
>> 1st, with release hopefully by June 1st.

> This sounds good to me.  Anyone object?

I'd like to set the target before PGCon not after; so May 1 or May 15.
Otherwise +1.

> The deciding people on "big patches" for the final commitfest should be
> a combination of the commitfest managers and the core team.  And we
> should weed out the disqualified before January 15.

As you say, we should reject outright (at the start of the final CF)
anything that's clearly too big.  But in the final 8.4 CF it didn't
really become clear until later on that some things were not ready or
were too big to deal with.  We need to be more willing to swing the axe
later in the fest, rather than allowing it to drag on "just a bit more"
in the hopes of getting big feature X in.

                        regards, tom lane

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

[Tom Lane-2]

Josh Berkus <josh@...> writes:
> One thing Peter forgot to mention here is that the next-to-last
> commitfest is the *last* commitfest for new major features.  For the
> *last* commitfest, any patch introduced either has to be a resubmission
> of something we've seen at a prior CF, or has to be very "small" (i.e.
> not many lines/files, no side effects, no API or defined standard API).

We've been kicking around variations of that idea already.

As I mentioned in the core discussion, I'm a bit concerned that this
would have the effect of choking off development too soon.  We could
have a situation where nothing major is supposed to be getting worked
on from Nov 15 to mid-May, which seems much too long.  So "very small"
seems too strict.  Robert's suggestion of a 1000-line cutoff might be
workable though.

                        regards, tom lane

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

[Richard Huxton]

Kevin Grittner wrote:

> Tom Lane <tgl@...> wrote:
>  
>> I think we used to do it more or less like that, but people
>> didn't like it because they couldn't do any long-range planning.
>  
> Well, obviously the 8.4 release cycle did little to help them.
>  
> As has already been observed, there is a crying need to say "no" at
> some point to get a release out.
>  
> It might actually help to do that on big patches if we don't let too
> many tiny ones accumulate.  I seem to remember the argument being tossed
> about that "we might as well keep working on this one because there's
> all these others to wrap up."

Have you chaps considered a simple points system? Every patch would need
  five minutes attention to triage it into one of: small (1 point),
medium (2), large (10), huge (50 points - Sync Repl etc). First CF gets
(say) 200 points, next 150, next 100, next 75. First-come, first-served
- if your patch goes over the limit it goes in the next commit-fest.

--
   Richard Huxton
   Archonet Ltd

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

[Stephen Frost]

* Tom Lane (tgl@...) wrote:

> Robert Haas <robertmhaas@...> writes:
> > What I think we have is a lot of people who are waiting
> > for feedback, and we should try to give them some.  I also know that
> > reviewing 60 patches for the November CommitFest was a ton of work,
> > and the reviewers (including the committers) ran out of steam well
> > before we got done.  That, and not any desire to jump the queue, is
> > the reason why I would like to get the reviewing process started
> > before the patch list grows unmanageably large.
>
> Yeah.  In core's private discussion of this, I too was arguing for
> running a CommitFest ASAP, in order to have some motion on the existing
> patch backlog.  I don't know that we'd actually end up committing many,
> but we need to provide feedback so people can take the next steps.

I'm in agreement that we should try to provide feedback (in general, to
be honest) on patches/suggestions/ideas/designs/etc as quickly as
possible.  The commitfest approach is good for this when it's "in
motion", but it's been stale for months.  +1 from me for starting early.

To flip it around a bit, I don't know that there's actually a moratorium
on providing feedback?  If people aren't busy working on 8.4 (I hope not
at this point, except testing.. :), have patches that they've submitted
and are waiting for feedback on, or aren't otherwise busy..  I say feel
free to pull patches and review/comment on.  As I like to tell the
people who work with me- being proactive and self-starting is almost
always looked on favorably.

I'm like to encourage the above for the entire development cycle, for
that matter.  Perhaps it won't change much (I'm confident we'll still
need a "commitfest mom", etc) but I don't see why we should actively
prevent it.

> People who *were* following the project calendar (like me for instance)
> have been largely ignoring the 8.5 queue, so many of those patches are
> just sitting out there without any substantive comment.

Certainly following the calendar is a good thing, it's just that we're
about to pass a milestone on the project calendar and need to decide
what we're gonna do next and when.

> Right at the moment I imagine a large fraction of those patches are
> broken anyway by the recent pgindent run --- has anyone checked?

I havn't yet, but it certainly sounds like a great idea.  Maybe we could
even have a "mini-fix-pgindent" commitfest in the last 2 weeks of July..

        Thanks,

                Stephen

[Stephen Frost]

* Tom Lane (tgl@...) wrote:
> I would like to propose aiming for a release around April/May 2010 ...
> "in time for PGCon" if you like, but the main point is to have it out
> before people start disappearing for summer break.  We've already run
> into problems with scheduling the 8.4 release because of that.

Big +1 from me for having it in time for PGCon.

> Or we could slide the target release date into the fall, but it seemed
> to me that the spring release timeframe worked better (or would have if
> we'd been able to meet it fully).

Agreed.

> Of the schedules Peter mentioned, the only one that has a realistic
> chance of releasing before June is the one with the final commitfest
> starting Feb 1.  Even then, we need to do something to prevent that
> fest from expanding the way the last 8.4 fest did.  The core committee
> speculated a bit about instituting a rule like "major patches must
> be submitted into a CF before the last one; the last one will only
> accept resubmissions and small patches".  But then you have to draw
> the line between major and minor patches.

I liked the general idea of only accepting "already been seen patches"
or "bug-fix only" patches in the last commitfest.

        Thanks,

                Stephen

[Stephen Frost]

* Tom Lane (tgl@...) wrote:
> As I mentioned in the core discussion, I'm a bit concerned that this
> would have the effect of choking off development too soon.  We could
> have a situation where nothing major is supposed to be getting worked
> on from Nov 15 to mid-May, which seems much too long.  So "very small"
> seems too strict.  Robert's suggestion of a 1000-line cutoff might be
> workable though.

Maybe we should have a hard rule now, but then leave ourselves the
option to relax it (perhaps not publically) once we actually get to the
last CF?  I dunno, just a thought.  I do share your concern about not
choking off development for too long, but it sure seems like we've
always got a big patch or two that we're trying to get into the next
release near the end..

        Thanks,

                Stephen

[Robert Haas]

On Tue, Jun 30, 2009 at 9:17 PM, Stephen Frost<sfrost@...> wrote:

> * Tom Lane (tgl@...) wrote:
>> As I mentioned in the core discussion, I'm a bit concerned that this
>> would have the effect of choking off development too soon.  We could
>> have a situation where nothing major is supposed to be getting worked
>> on from Nov 15 to mid-May, which seems much too long.  So "very small"
>> seems too strict.  Robert's suggestion of a 1000-line cutoff might be
>> workable though.
>
> Maybe we should have a hard rule now, but then leave ourselves the
> option to relax it (perhaps not publically) once we actually get to the
> last CF?  I dunno, just a thought.  I do share your concern about not
> choking off development for too long, but it sure seems like we've
> always got a big patch or two that we're trying to get into the next
> release near the end..

With all due respect, you guys are worrying about the wrong problem.
I suspect it's much more likely that we're going to want to postpone
900-line patches than it is that you're going to want to not postpone
1100-line patches.  If by some chance Tom wants to commit an 1100-line
patch submitted three weeks after the start of the last CommitFest,
he'll explain why he wants to do it and in all likelihood the rest of
us will shrug our shoulders and say "OK, do it".  But I seriously
doubt that's gonna happen.  What's a lot more likely is that Tom will
look at a 900-line patch submitted three weeks BEFORE the start of the
last CommitFest and say "this is going to break a lot of stuff, we
should bounce this to 8.6", and everyone will say "no, it's a great
feature, commit the broken code now! now, we say!".

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

Stephen Frost <sfrost@...> writes:
> * Tom Lane (tgl@...) wrote:
>> Yeah.  In core's private discussion of this, I too was arguing for
>> running a CommitFest ASAP, in order to have some motion on the existing
>> patch backlog.  I don't know that we'd actually end up committing many,
>> but we need to provide feedback so people can take the next steps.

> I'm in agreement that we should try to provide feedback (in general, to
> be honest) on patches/suggestions/ideas/designs/etc as quickly as
> possible.  The commitfest approach is good for this when it's "in
> motion", but it's been stale for months.  +1 from me for starting early.

> To flip it around a bit, I don't know that there's actually a moratorium
> on providing feedback?

Well, I wouldn't put it as strongly as "moratorium", but ... the point
of having a release cycle is that at certain times people are supposed
to focus on stabilizing and testing a release, not on working on new
development.  If, at any time in the past six months, I were to have
gone off and reviewed a patch that's clearly 8.5 material, that's
man-hours taken directly away from getting a solid 8.4 release out the
door.  Which means that much longer until 8.4 does get out, which hurts
everybody including the submitter of the premature patch.  So in general
I agree with the viewpoint Peter outlined that working on new
development during beta period is not really playing by the rules, and
that people who expect feedback for new development during beta period
simply don't understand how the project is supposed to work.

If you find yourself with nothing else to do except review a new patch
during beta, then sure, go do it.  But is there *really* nothing you
could be doing to help expedite the beta?

Anyway, as of now that's all moot until next spring.  But it's still
true that people want time to work on their own patches, which is why
we came up with the commitfests.  It's so you can get some time to work
without feeling guilty about not reviewing other people's work instead.

                        regards, tom lane

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

[Andrew Dunstan]

Josh Berkus wrote:
>
> One thing Peter forgot to mention here is that the next-to-last
> commitfest is the *last* commitfest for new major features.  For the
> *last* commitfest, any patch introduced either has to be a
> resubmission of something we've seen at a prior CF, or has to be very
> "small" (i.e. not many lines/files, no side effects, no API or defined
> standard API).
>
> This makes the next-to-last CF our "biggest" CF.

I thought we discussed that at pgCon in May and rejected it.

I have very, very serious reservations about it. I think we need to get
better about proper triage, especially on the final commitfest, rather
than moving the effective feature freeze back a whole commitfest.

ISTM we're in danger of becoming dominated by procedures. Let's keep it
light and loose.

cheers

andrew

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

[Stephen Frost]

* Tom Lane (tgl@...) wrote:

> Stephen Frost <sfrost@...> writes:
> > I'm in agreement that we should try to provide feedback (in general, to
> > be honest) on patches/suggestions/ideas/designs/etc as quickly as
> > possible.  The commitfest approach is good for this when it's "in
> > motion", but it's been stale for months.  +1 from me for starting early.
>
> > To flip it around a bit, I don't know that there's actually a moratorium
> > on providing feedback?
>
> Well, I wouldn't put it as strongly as "moratorium", but ... the point
> of having a release cycle is that at certain times people are supposed
> to focus on stabilizing and testing a release, not on working on new
> development.  

I certainly agree with this.  I tried to qualify my comment above in the
sentence which followed it, but apparently I didn't do a good job.

- This only applies before feature freeze (eg: right after 8.4 is out)
- No work being done on a current patch (eg: waiting for feedback)
- Have cycles to spare

Our current arrangment is based on a premise that a given person will
have X cycles in a month to work on PG, and that they have >=X amount
of work to do on developing their patch(s) that month.  I feel like
there are a number of patch submitters who have X cycles to work on PG,
and <X work they'll be able to do on their patch in a given month (in
part because at some point they'll submit it and then wait for
feedback).  I see minimial drawback to encouraging those people to
review other patches with any extra cycles they have, even if we're not
actually in a CF-mode at that point.

> If, at any time in the past six months, I were to have
> gone off and reviewed a patch that's clearly 8.5 material, that's
> man-hours taken directly away from getting a solid 8.4 release out the
> door.  Which means that much longer until 8.4 does get out, which hurts
> everybody including the submitter of the premature patch.  So in general
> I agree with the viewpoint Peter outlined that working on new
> development during beta period is not really playing by the rules, and
> that people who expect feedback for new development during beta period
> simply don't understand how the project is supposed to work.

It wasn't my intent to imply this would be done during feature-freeze,
or beta, but rather something to be done during development.  Perhaps I
should have phrased it as "the moratorium on looking at patches can end
when 8.4 is released, and not be fully reinstated until 8.5 beta".

> Anyway, as of now that's all moot until next spring.  But it's still
> true that people want time to work on their own patches, which is why
> we came up with the commitfests.  It's so you can get some time to work
> without feeling guilty about not reviewing other people's work instead.

I definitely think that's good, and to be honest I don't think my
suggestion would apply to core much at all (they've always got >=X work
to do on patches :), but as we saw during the commitfests in 8.4,
there's a number of non-core folks out there volunteering to review.  If
they're willing and able to spend cycles reviewing other patches rather
than twiddling their thumbs waiting for feedback, let's encourage that.

        Thanks,

                Stephen

[Bruce Momjian-5]

Tom Lane wrote:

> > As for thresholds, I'd propose that we measure the size of patches
> > using "diff -u | diffstat".  If the number of insertions plus the
> > number of deletions is >= 1000, then the patch is not eligible for the
> > final CommitFest unless it was submitted for the penultimate
> > CommitFest.  This obvious discriminates against patches with a large
> > footprint that are not very invasive and in favor of those with a
> > small footprint that are more destabilizing, but it's a clean line in
> > the sand, and I think having such a line is better than trying to
> > apply human judgment to every case.
>
> Well, in the end it will come down to committers' judgements anyway;
> if someone thinks a patch is ready it will probably go in, regardless
> of size.  But this gives us another tool for saying "no", so I'm
> agreeable ;-)

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 earily would not have significantly
moved the release date earlier.

--
  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 Tue, Jun 30, 2009 at 11:18 PM, Bruce Momjian<bruce@...> wrote:

> Tom Lane wrote:
>> > As for thresholds, I'd propose that we measure the size of patches
>> > using "diff -u | diffstat".  If the number of insertions plus the
>> > number of deletions is >= 1000, then the patch is not eligible for the
>> > final CommitFest unless it was submitted for the penultimate
>> > CommitFest.  This obvious discriminates against patches with a large
>> > footprint that are not very invasive and in favor of those with a
>> > small footprint that are more destabilizing, but it's a clean line in
>> > the sand, and I think having such a line is better than trying to
>> > apply human judgment to every case.
>>
>> Well, in the end it will come down to committers' judgements anyway;
>> if someone thinks a patch is ready it will probably go in, regardless
>> of size.  But this gives us another tool for saying "no", so I'm
>> agreeable ;-)
>
> 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 earily would not have significantly
> moved the release date earlier.

I don't believe it.  :-)

If the large patches had been rejected earlier, the reviewers and
committers who were spending time on them could have started spending
time on other things sooner.

I also believe, although I cannot prove it, that it would have
increased the pressure to get the remaining items dealt with.  When
there are 100 patches, everyone can say "oh, well it doesn't matter
whether I get this taken care of today, because there will still be 99
other patches".  When there are 3 patches, that argument doesn't hold
water.

Another thing I'd like to improve for the next CommitFest is the
communication between reviewers and committers.  In the November
CommitFest, I, and I think others, assumed that the committers were
reading all of the review threads in detail throughout the process and
that they would jump in when things got close to being done, or maybe
when things got marked as Ready for Committer on the Wiki.  That
worked OK, but there were rough patches where things bogged down.  As
much as we may express opinions on the merits of certain patches, I
think all of us non-committers are (certainly I am) loathe to avoid
the perception that we're telling the committers what to do.  But, I
think it would be helpful to have periodic updates on what the
different committers are currently focused on, how long they intend to
be focused on that, and what they intend to focus on next; and I think
it would be helpful for the CF mgmt team to make suggestions as to
what patches we think are the closest to being ready to go or most in
need of committer-level input.

...Robert

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