On Thu, 2007-04-26 at 23:13 -0400, Bruce Momjian wrote: > Our community could probably handle a few of these complex patches, but > the volume for this release is significantly higher than previous > releases. The community is doing a good job of giving patch writers > feedback and new patch versions are getting generated. However, this > amount of patch churn is not normal.
I think it is probably going to be normal from now on. We now a significant number of reasonably prolific developers. > I think the community has to come up with ideas on how to accomplish this. My thinking is to move to a two stage release process: Do one "production" release annually, and one "dev" release at the 6 month mid-point. That way each new release contains a manageable number of new features and we have a realistic chance of integrating them successfully. Support companies would then have the option to support both releases, or just the main production release. Leading edge users, of which we have many, would then benefit from more frequent additional features. I would also suggest that 8.3 be labelled a dev release. We have a reasonable number of fairly invasive patches, so we need a mechanism to integrate them with reduced risk. With those two suggestions, the prod release would freeze on Sep 30 and the dev release on Mar 31. This would then put us into the same situation as Linux, where odd-numbered releases are dev and even-numbered are main releases. Everyone would understand our decision to take this action, as well as immediately understanding how this process will work in the future. By agreeing this now, we can then punt a reasonable number of patches back to the main release, later this year. The de-selected patches still have a second chance of making it into a release available in 2007 and this will diffuse the various tensions and difficulties we now have. Without this, we face a long wait. 8.2 took 4 months to go through beta and release, so 8.3 could well take 6 months. If we allow 8.3 to be a mega-release then it might take much longer than that: increases in complexity have a non-linear effect on software quality/robustness. Adding reviewers or committers isn't going to dramatically change that. IMHO the only sensible thing to do is to make releases more frequent so that each one is still a manageable size. The alternative is to somehow select patches to wait until the next release, a full year away. That is unlikely to be an easy process and nobody really wants to volunteer their own or others' patches. Realistically, people won't speed up the frequency they upgrade their software and we certainly don't want to increase the number of production releases in circulation that we must support. This set of proposals is a realistic way forward from where we are and will be easily explained to people only briefly in touch with our project. Whether or not this is accepted, I'm happy to offer assistance wherever the core team directs to improve the current situation. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate