branching for 9.2devel

On 04/25/2011 09:17 AM, Robert Haas wrote:

The recent and wide-ranging "formatting curmudgeons" thread included
suggestions by Tom and myself that we should consider branching the
tree immediately after beta1.

http://archives.postgresql.org/pgsql-hackers/2011-04/msg01157.php
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01162.php

This didn't get much commentary, but others have expressed support for
similar ideas in the past, so perhaps we should do it? Comments?

I am on record in the past as supporting earlier branching.

cheers

andrew

* Robert Haas (robertmhaas@gmail.com) wrote:

On balance, I think I prefer the
current arrangement, though if we could make the CommitFests a bit
shorter I would certainly like that better. I don't know how to make
that happen without more reviewers, though.

Given our current method (where we allow authors to update their patches
during a CF) I don't see that we need or should try for shorter CFs. If
we actually just reviewed patches onces it'd be a very different
situation.

So, +1 from me for keeping it as-is. I do wonder if this is coming up
now just because we're getting closer to a release and people are,
unsuprisingly, wishing they had been able to get their fav. patch in
before the deadline. :)

Thanks,

Stephen

Robert Haas <robertmhaas@gmail.com> wrote:

The recent and wide-ranging "formatting curmudgeons" thread
included suggestions by Tom and myself that we should consider
branching the tree immediately after beta1.

My take is that it should be branched as soon as a committer would
find it useful to commit something destined for 9.2 instead of 9.1.
If *any* committer feels it would be beneficial, that seems like
prima facie evidence that it is needed, barring a convincing
argument to the contrary.

The other major issue discussed on the thread was as to how
frequent and how long CommitFests should be.

On balance, I think I prefer the current arrangement, though if we
could make the CommitFests a bit shorter I would certainly like
that better. I don't know how to make that happen without more
reviewers, though.

Agreed. It is hard to picture doing shorter commit fests without
that just pushing more of the initial review burden to the
committers. Besides the normal "herding cats" dynamic, there is
that matter of schedules in an all-volunteer project. When I've
managed CFs, there have been people who were on vacation or under
the deadline to complete a major paper during the first week of the
CF who were able to contribute later. Some non-committer reviewers
were able to complete review of one patch and move on to others.

During the weeks of a single CF some patches go through multiple
critiques which send them back to the author, so I'm not sure how
much a shorter cycle would help with that issue for non-committer
reviews. Perhaps we will get some of the stated benefits of shorter
CF cycles as reviewers become more skilled and patches get to the
reviewers with fewer problems. Maybe we could encourage reviewers
to follow patches which they have moved to "Ready for Committer"
status, to see what the committers find that they missed, to help
develop better skills.

-Kevin

Robert Haas <robertmhaas@gmail.com> writes:

The recent and wide-ranging "formatting curmudgeons" thread included
suggestions by Tom and myself that we should consider branching the
tree immediately after beta1.
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01157.php
http://archives.postgresql.org/pgsql-hackers/2011-04/msg01162.php
This didn't get much commentary, but others have expressed support for
similar ideas in the past, so perhaps we should do it? Comments?

One small issue that would have to be resolved before branching is
whether and when to do a "final" pgindent run for 9.1. Seems like the
alternatives would be:
1. Don't do anything more, be happy with the one run done already.
2. Do another run just before branching.
3. Make concurrent runs against HEAD and 9.1 branch sometime later.
I don't much care for #3 because it would also affect whatever
developmental work had been done to that point, and thus have a
considerable likelihood of causing merge problems for WIP patches.
Not sure if enough has happened to really require #2.

But a much more significant issue is that I don't see a lot of point in
branching until we are actually ready to start active 9.2 development.
So unless you see this as a vehicle whereby committers get to start
hacking 9.2 but nobody else does, there's no point in cutting a branch
until shortly before a CommitFest opens. I'm not aware that we've set
any dates for 9.2 CommitFests yet ...

The other major issue discussed on the thread was as to how frequent
and how long CommitFests should be. I don't think we really came to a
consensus on that one.

Yeah, it did not seem like there was enough evidence to justify a
change, and Greg's comments were discouraging. (Though you've run more
fests than he has, so I was surprised that you weren't arguing
similarly.) Should we consider scheduling one short-cycle fest during
9.2, just to see whether it works?

regards, tom lane

On Mon, Apr 25, 2011 at 3:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

One small issue that would have to be resolved before branching is
whether and when to do a "final" pgindent run for 9.1.  Seems like the
alternatives would be:

If the tools become easy to run is it possible we cold get to the
point where we do an indent run on every commit? This wold require a
stable list of system symbols plus the tool would need to add any new
symbols added by the patch. As long as the tool produced consistent
output I don't see that it would produce the spurious merge conflicts
we've been afraid of in the past. Those would only occur if a patch
went in without pgindent being run, someone developed a patch against
that tree, then pgindent was run before merging that patch. As long as
it's run on every patch on commit it shouldn't cause those problems
since nobody could use a non-pgindented code as their base.

Personally I've never really liked the pgindent run. White-space
always seemed like the least interesting of the code style issues,
none of which seemed terribly important compared to the more important
things like staying warning-clean and defensive coding rules. But if
we're going to do it letting things diverge for a whole release and
then running it once a year seems the worst of both worlds.

--
greg

Greg Stark <gsstark@mit.edu> writes:

If the tools become easy to run is it possible we cold get to the
point where we do an indent run on every commit? This wold require a
stable list of system symbols plus the tool would need to add any new
symbols added by the patch. As long as the tool produced consistent
output I don't see that it would produce the spurious merge conflicts
we've been afraid of in the past. Those would only occur if a patch
went in without pgindent being run, someone developed a patch against
that tree, then pgindent was run before merging that patch. As long as
it's run on every patch on commit it shouldn't cause those problems
since nobody could use a non-pgindented code as their base.

No, not at all, because you're ignoring the common case of a series of
dependent patches that are submitted in advance of the first one having
been committed.

To get to the point where we could do things that way, it would have
to be the case that every developer could run pgindent locally and get
the same results that the committer would get. Maybe we'll get there
someday, and we should certainly try. But we're not nearly close enough
to be considering changing policy on that basis.

Personally I've never really liked the pgindent run.

If everybody followed roughly the same coding/layout standards without
prompting, we'd not need it. But they don't so we do. I think pgindent
gets a not-trivial share of the credit for the frequently-mentioned fact
that the PG sources are pretty readable.

regards, tom lane

On Mon, Apr 25, 2011 at 11:03 AM, Greg Stark <gsstark@mit.edu> wrote:

If the tools become easy to run is it possible we cold get to the
point where we do an indent run on every commit? This wold require a
stable list of system symbols plus the tool would need to add any new
symbols added by the patch.

Methinks there'd need to be an experiment run where pgindent is run
each time on some sort of "parallel tree" for a little while, to let
people get some feel for what changes it introduces.

Unfortunately, I'd fully expect there to be some interference between patches.

Your patch changes the indentation of the code a little, breaking the
patch I wanted to submit just a little later. And, by the way, I had
already submitted my patch. So you broke my patch, even though mine
was contributed first.

That seems a little antisocial...
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

One small issue that would have to be resolved before branching is
whether and when to do a "final" pgindent run for 9.1.  Seems like the
alternatives would be:
       1. Don't do anything more, be happy with the one run done already.
       2. Do another run just before branching.
       3. Make concurrent runs against HEAD and 9.1 branch sometime later.
I don't much care for #3 because it would also affect whatever
developmental work had been done to that point, and thus have a
considerable likelihood of causing merge problems for WIP patches.
Not sure if enough has happened to really require #2.

I'd vote for #1, unless by doing #2 we can fix the problems created by
omission of some typedefs from the symbol tables emitted by newer gcc
versions.

But a much more significant issue is that I don't see a lot of point in
branching until we are actually ready to start active 9.2 development.
So unless you see this as a vehicle whereby committers get to start
hacking 9.2 but nobody else does, there's no point in cutting a branch
until shortly before a CommitFest opens.  I'm not aware that we've set
any dates for 9.2 CommitFests yet ...

That doesn't strike me as a condition prerequisite for opening the
tree. If anything, I'd say we ought to decide first when we'll be
open for development (current question) and then schedule CommitFests
around that. And I do think there is some value in having the tree
open even if we haven't gotten the schedule quite hammered out yet,
because even if we don't have any formal process in place to be
working through the 9.2 queue, some people might choose to work on it
anyway.

The other major issue discussed on the thread was as to how frequent
and how long CommitFests should be.  I don't think we really came to a
consensus on that one.

Yeah, it did not seem like there was enough evidence to justify a
change, and Greg's comments were discouraging.  (Though you've run more
fests than he has, so I was surprised that you weren't arguing
similarly.)  Should we consider scheduling one short-cycle fest during
9.2, just to see whether it works?

Well, I basically think Greg is right, but the process is so darn much
work that I don't want to be too quick to shut down ideas for
improvement. If we do a one-week CommitFest, then there is time for
ONE review. Either a reviewer will do it, and no committer will look
at it, or the other way around, but it will not get the level of
attention that it does today. There is a huge amount of work involved
on getting "up to speed" on a patch, and so it really makes a lot more
sense to me to do it in a sustained push than in little dribs and
drabs. I have to think my productivity would be halved by spending a
week on it and then throwing in the towel.

I'm inclined to suggest that we just go ahead and schedule five
CommitFests, using the same schedule we have used for the last couple
of releases, but with one more inserted at the front end:

May 15, 2011 - June 14, 2011
July 15, 2011 - August 14, 2011
September 15, 2011 - October 14, 2011
November 15, 2011 - December 14, 2011
January 15, 2012 - February 14, 2012

I also think we should also publicize as widely as possible that
design proposals are welcome any time. Maybe that's not what we've
said in the past, but I think it's the new normal, and we should make
sure people know that. And I think we should reaffirm our previous
commitment not to accept new, previously-unreviewed large patches in
the last CommitFest. If anything we should strengthen it in some way.
The crush of 100 patches in the last CF of the 9.1 cycle was entirely
due to people waiting until the last minute, and a lot of that stuff
was pretty half-baked, including a bunch of things that got committed
after substantial further baking that should properly have been done
much sooner.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Apr 25, 2011 at 11:32 AM, Christopher Browne <cbbrowne@gmail.com> wrote:

Methinks there'd need to be an experiment run where pgindent is run
each time on some sort of "parallel tree" for a little while, to let
people get some feel for what changes it introduces.

The point is that if the tools worked "everywhere", "the same", then
it it should be run *before* the commit is finalized (git has a
hundred+1 ways to get this to happen, be creative).

So if you ever ran it on a $COMMIT from the published tree, it would
never do anything.

From the sounds of it though, it's not quite ready for that.

Unfortunately, I'd fully expect there to be some interference between patches.

Your patch changes the indentation of the code a little, breaking the
patch I wanted to submit just a little later.  And, by the way, I had
already submitted my patch.  So you broke my patch, even though mine
was contributed first.

But if the only thing changed was the indentation level (because
$PATCH2 wrapped a section of code your $PATCH1 changes completely in a
new block, or removed a block level), git tools are pretty good at
handling that.

So, if everything is *always* pgindent clean, that means your new
patch is too, and the only conflicting white-space-only change would
be a complete block-level indentation (easily handled). And you still
have those block-level indentation changes even if not using pgindent.

Of course, that all depends on:
1) pgindent being "work everywhere", "exactly the same"
2) Discipline of all new published commits being "pgindent clean".

a.

--
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

Robert Haas <robertmhaas@gmail.com> writes:

On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

But a much more significant issue is that I don't see a lot of point in
branching until we are actually ready to start active 9.2 development.
So unless you see this as a vehicle whereby committers get to start
hacking 9.2 but nobody else does, there's no point in cutting a branch
until shortly before a CommitFest opens. �I'm not aware that we've set
any dates for 9.2 CommitFests yet ...

That doesn't strike me as a condition prerequisite for opening the
tree. If anything, I'd say we ought to decide first when we'll be
open for development (current question) and then schedule CommitFests
around that. And I do think there is some value in having the tree
open even if we haven't gotten the schedule quite hammered out yet,
because even if we don't have any formal process in place to be
working through the 9.2 queue, some people might choose to work on it
anyway.

You're ignoring the extremely real costs involved in an early branch,
namely having to double-patch every bug fix we make during beta.
(And no, my experiences with git cherry-pick are not so pleasant as
to make me feel that that's a non-problem.) I really don't think that
we should branch until we're willing to start doing 9.2 development in
earnest. You're essentially saying that we should encourage committers
to do some cowboy committing of whatever 9.2 stuff seems ready, and
never mind the distributed costs that imposes on the rest of the
project. I don't buy that.

IOW, the decision process ought to be set 9.2 schedule -> set CF dates
-> set branch date. You're attacking it from the wrong end.

I'm inclined to suggest that we just go ahead and schedule five
CommitFests, using the same schedule we have used for the last couple
of releases, but with one more inserted at the front end:

May 15, 2011 - June 14, 2011
July 15, 2011 - August 14, 2011
September 15, 2011 - October 14, 2011
November 15, 2011 - December 14, 2011
January 15, 2012 - February 14, 2012

Well, if you go with that, then I will personally refuse to have
anything to do with the first CF, because I was intending to spend
my non-bug-fix time during beta on reading the already committed but
probably still pretty buggy stuff from 9.1 (SSI and SR in particular).
I think a schedule like the above will guarantee that no beta testing
gets done by the development community at all, which will be great for
moving 9.2 along and terrible for the release quality of 9.1.

I think the earliest we could start a CF without blowing off the beta
process entirely is June. Maybe we could start CFs June 1, August 1,
etc?

regards, tom lane

Aidan Van Dyk <aidan@highrise.ca> wrote:

2) Discipline of all new published commits being "pgindent clean".

Heck, I think it would be reasonable to require that patch
submitters run it before creating their patches. If people merged
in changes from the main repository and then ran pgindent, I don't
think there would be much in the way of merge problems from it.

Personally, once I had pgindent set up I didn't find running it any
more onerous than running filterdiff to get things into context diff
format. (That is, both seemed pretty trivial.)

The problem is that getting it set up isn't yet trivial. This is
all assuming that we fix that.

-Kevin

On Mon, Apr 25, 2011 at 12:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

You're ignoring the extremely real costs involved in an early branch,
namely having to double-patch every bug fix we make during beta.
(And no, my experiences with git cherry-pick are not so pleasant as
to make me feel that that's a non-problem.)  I really don't think that
we should branch until we're willing to start doing 9.2 development in
earnest.  You're essentially saying that we should encourage committers
to do some cowboy committing of whatever 9.2 stuff seems ready, and
never mind the distributed costs that imposes on the rest of the
project.  I don't buy that.

IOW, the decision process ought to be set 9.2 schedule -> set CF dates
-> set branch date.  You're attacking it from the wrong end.

I'm inclined to suggest that we just go ahead and schedule five
CommitFests, using the same schedule we have used for the last couple
of releases, but with one more inserted at the front end:

May 15, 2011 - June 14, 2011
July 15, 2011 - August 14, 2011
September 15, 2011 - October 14, 2011
November 15, 2011 - December 14, 2011
January 15, 2012 - February 14, 2012

Well, if you go with that, then I will personally refuse to have
anything to do with the first CF, because I was intending to spend
my non-bug-fix time during beta on reading the already committed but
probably still pretty buggy stuff from 9.1 (SSI and SR in particular).
I think a schedule like the above will guarantee that no beta testing
gets done by the development community at all, which will be great for
moving 9.2 along and terrible for the release quality of 9.1.

I think the earliest we could start a CF without blowing off the beta
process entirely is June.  Maybe we could start CFs June 1, August 1,
etc?

I can't object to taking another two weeks, especially since that
would give people who may have been expecting a later branch more time
to get their stuff into shape for CF1.

One problem with that is that it would make the fourth CommitFest
start on December 1st, which will tend to make that CommitFest pretty
half-baked, due to the large number of PostgreSQL developers who
observe Christmas. That seems particularly bad if we're planning to
end the cycle at that point. Perhaps that would be a good time to
employ Peter's idea for a short, one week CommitFest:

CF #1: June 1-30
CF #2: August 1-31
CF #3: October 1-31
CF #4 (one week shortened CF): December 1-7
CF #5: January 1-31

That would give people another crack at getting feedback before the
final push, right at the time of the release cycle when timely
feedback becomes most important.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Aidan Van Dyk <aidan@highrise.ca> wrote:

Of course, that all depends on:
1) pgindent being "work everywhere", "exactly the same"
2) Discipline of all new published commits being "pgindent clean".

The problem is that getting it set up isn't yet trivial. This is
all assuming that we fix that.

Yeah, there is not much point in thinking about #2 until we have #1.

regards, tom lane

On Mon, Apr 25, 2011 at 1:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Aidan Van Dyk <aidan@highrise.ca> wrote:

Of course, that all depends on:
1) pgindent being "work everywhere", "exactly the same"
2) Discipline of all new published commits being "pgindent clean".

The problem is that getting it set up isn't yet trivial.   This is
all assuming that we fix that.

Yeah, there is not much point in thinking about #2 until we have #1.

Would this be a good GSoC project (or has the deadline passed)?

--
Thanks,

David Blewett

On 04/25/2011 01:12 PM, David Blewett wrote:

On Mon, Apr 25, 2011 at 1:04 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:

"Kevin Grittner"<Kevin.Grittner@wicourts.gov> writes:

Aidan Van Dyk<aidan@highrise.ca> wrote:

Of course, that all depends on:
1) pgindent being "work everywhere", "exactly the same"
2) Discipline of all new published commits being "pgindent clean".

The problem is that getting it set up isn't yet trivial. This is
all assuming that we fix that.

Yeah, there is not much point in thinking about #2 until we have #1.

Would this be a good GSoC project (or has the deadline passed)?

Greg Smith and I have done some work on it, and we're going to discuss
it at pgCon. I don't think there's terribly far to go.

cheers

andrew

On mån, 2011-04-25 at 09:17 -0400, Robert Haas wrote:

it'll be harder to organize reviewers (see esp. the note
by Greg Smith in that regard),

As far as I'm concerned, those who run the commit fests will have to
work out how to best configure the commit fests. I have no strong
feelings about my various suggestions; they were just ideas.

Altogether, I feel that keeping it the same is probably the more
acceptable option at the moment.

All,

�I'm not aware that we've set

any dates for 9.2 CommitFests yet ...

I thought the idea of setting the initial CF for July 15th for 9.1 was
that we would consistently have the first CF in July every year? As
discussed at that time, there's value to our corporate-sponsored
developers in knowing a regular annual cycle.

As much as I'd like to start development early officially, I'm with Tom
in being pessimistic about the bugs we're going to find in SSI,
Collations and Synch Rep. Frankly, if you and Tom weren't so focused on
fixing it, I'd be suggesting that we pull Collations from 9.1; there
seems to be a *lot* of untested issues there still.

I do think that we could bump the first CF up to July 1st, but I don't
think sooner than that is realistic without harming beta testing ... and
potentially delaying the release. Let's first demonstrate a track
record in getting a final release out consistently by July, and if that
works, maybe we can bump up the date.

=============

Re: shorter CF cycle: this works based on the idea of a "one strike" for
each patch. That has the benefit of pushing more of the fixing work
onto the authors and having less of it on the committers: "Not ready,
fix X,Y,Z and resubmit."

I think that doing thing that way might actually work. However, it will
require us to change the CF process in several ways. I'll also point
out that pushing fixing work back on the authors is something which
committers could be doing *already* in the present structure. And that
there's no requirement that our present CFs need to last for a month.

The main issues with a "monthly commit week" are:

1) Triage: it's hard to go from first-time reviewer --> review -->
committer in a week, so a lot of patches would get booted the next CF
just due to time, and

2) availability: some patches can only be understood by certain
committers, who are more likely to be gone for a week than a month, and

3) The CF tool, which is currently fairly manual when it comes to
pushing a patch from one CF to the other. This is the easiest thing to fix.

However, given all that, there would be some serious advantages to a
monthly commit week:

a) faster feedback to submitters, and

b) more chances for a developer to fix their feature and try again, and

c) more of an emphasis on having the submitter fix what's wrong based on
advice, which
* conserves scarce committer time, and
* helps the submitters learn more and become better coders

d) eliminates the annoying dead time in each CF, where for the last week
of the CF only 2 extremely difficult patches are under review, and

e) eliminates the stigma/trauma of having your stuff rejected because
everyone's stuff will be rejected at least once before acceptance, and

f) even allows us to punt on "everything must be reviewed" if nothing
gets punted more than once.

Overall, I think the advantages to a faster/shorter CF cycle outweigh
the disadvantages enough to make it at least worth trying. I'm willing
to run the first 1-week CF, as well as several of the others during the
9.2 cycle to try and make it work.

I also have an idea for dealing with Problem 1: we actually have 2
weeks, a "triage week" and a "commitfest week". During the Triage
week, non-committer volunteers will go through the pending patches and
flag stuff which is obviously either broken or ready. That way, by the
time committers actually need to review stuff during CF week, the easy
patches will have already been eliminated. Not only will this
streamline processing of the patches, it'll help us train new reviewers
by giving them a crack at the easy reviews before Tom/Robert/Heikki look
at them.

It may not work. I think it's worth trying though, and we can always
revert to the present system if the 1-week CFs are impeding development
or are accumulating a snowball of patch backlog.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

On Mon, Apr 25, 2011 at 4:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

No, not at all, because you're ignoring the common case of a series of
dependent patches that are submitted in advance of the first one having
been committed.

Uh, true.

To get to the point where we could do things that way, it would have
to be the case that every developer could run pgindent locally and get
the same results that the committer would get.  Maybe we'll get there
someday, and we should certainly try.  But we're not nearly close enough
to be considering changing policy on that basis.

Fwiw I tried getting Gnu indent to work. I'm having a devil of a time
figuring out how to get even remotely similar output.

I can't even get -ncsb to work which means it puts *every* one-line
comment into a block with the /* and */ delimiters on a line by
themselves. And it does line-wrapping differently such that any lines
longer than the limit are split at the *first* convenient place rather
than the last which produces some, imho, strange looking lines.

And it doesn't take a file for the list of typedefs. You have to
provide each one as an argment on the command-line. I hacked the
source to add the typedefs to the gperf hash it uses but if we have to
patch it it rather defeats the point of even pondering switching.

Afaict it hasn't seen development since 2008 so I don't get the
impression it's any more of a live project than the NetBSD source.

All in all even if they've fixed the things it used to mangle I don't
see much point in switching from one moribund project we have to patch
to another moribund project we have to patch, especially as it will
mean patches won't backpatch as easily since the output will be quite
different.

--
greg

Josh Berkus <josh@agliodbs.com> writes:

As much as I'd like to start development early officially, I'm with Tom
in being pessimistic about the bugs we're going to find in SSI,
Collations and Synch Rep. Frankly, if you and Tom weren't so focused on
fixing it, I'd be suggesting that we pull Collations from 9.1; there
seems to be a *lot* of untested issues there still.

If I had realized two months ago what poor shape the collations patch
was in, I would have argued to pull it. But the work is done now;
there's no reason not to keep it in. The cost is that I wasn't paying
any attention to these other areas for those two months, and we can't
get that back by pulling the feature.

I do think that we could bump the first CF up to July 1st, but I don't
think sooner than that is realistic without harming beta testing ... and
potentially delaying the release. Let's first demonstrate a track
record in getting a final release out consistently by July, and if that
works, maybe we can bump up the date.

The start-date-on-the-15th was an oddity anyway, and it cannot work well
in November or December. +1 for putting the CFs back to starting on the
1st.

Overall, I think the advantages to a faster/shorter CF cycle outweigh
the disadvantages enough to make it at least worth trying. I'm willing
to run the first 1-week CF, as well as several of the others during the
9.2 cycle to try and make it work.

I think we could try this once or twice without committing to doing the
whole 9.2 cycle that way.

I also have an idea for dealing with Problem 1: we actually have 2
weeks, a "triage week" and a "commitfest week". During the Triage
week, non-committer volunteers will go through the pending patches and
flag stuff which is obviously either broken or ready. That way, by the
time committers actually need to review stuff during CF week, the easy
patches will have already been eliminated. Not only will this
streamline processing of the patches, it'll help us train new reviewers
by giving them a crack at the easy reviews before Tom/Robert/Heikki look
at them.

We've sort of unofficially done that already, in that lately it seems
the committers don't pay much attention to a new fest until several days
in, when things start to reach "ready for committer" state. That
behavior would definitely not work very well in 1-week CFs, so I agree
that some kind of multi-stage design would be needed.

regards, tom lane