Robert Haas <robertmh...@gmail.com> writes: > It seems that you're sort of frustrated with the system and the need > to go through a process before committing a patch;
I've been handling arround here for years (since 2005 or before) and I think there always was a process. The only change is it's getting more and more formal. But still not any clearer. It's good to try to keep the major releases one year apart, but until now we had some flexibility towards developpers. They could have their own agenda then appear with a big patch and it was getting considered. We never asked contributors to arrange for being able to find a sponsor, do the closed source version, prepare for publishing, and then send a patch in a timely maneer so that to ease the integration and release. Before there was a Commit Fest process, we took some weeks then months at the end of the cycle to consider what had been accumulated. The new process is there for giving more feedback to developpers, and is being considered now as a way to get better control about the release agenda. I'm not sure it's a good tool for that. I'm not sure insisting that much on the release schedule is a good idea. Once more making compromises is easy. What's hard and challenging is making *good* compromises. > IMHO, our system has to work for both developers and users, and it has > to work for both committers and non-committers. That's an easy goal to share. The question is how you get there without losing existing developpers and possibly attracting new developpers on the way. -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers