On Mon, Apr 25, 2011 at 10:45 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
