Robert Haas <robertmhaas@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