Re: branching for 9.2devel

On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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