> You're suggestion doesn't help with the problem that (like Joshua already
> mentioned) core developers are too busy with reviewing stuff during the
> CommitFest. Because of this it's really hard to get the necessary time of
> somebody who is able to evaluate the architecture of a new feature and (more
> important) its side-effects on the whole system. Especially the last
> CommitFest before Feature Freeze is becoming heavily busted with many many
> interesting patches, because people want to have their WIP reviewed at least
> for the upcoming release (like me). I don't see how postponing patches would
> make it better?
Hmm, well, I'm only talking about postponing patches that aren't ready
to be committed, and then only if their authors don't respond to
feedback in a timely fashion. I agree that it would be nice if the
core developers had more time to provide more feedback to more people,
but that seems like an unrelated problem, and in any event I don't
know how to solve it, other than by hoping that we'll eventually have
more core developers.
On the other hand, it's easy to draw a line from the lax criteria for
resubmitting patches to the length of this CommitFest. It now appears
that this CommitFest will be something like 3.5 months long and that
the next one will not occur before May. That means we're essentially
closed to new patches for six months, which is a really long time. To
put it another way, for every week the core team spends reworking the
existing patches, it will be another week before someone can get
feedback on any new patches submitted now. At some point that becomes
a bad trade-off for the project as a whole. Judging when exactly
you've hit that point is difficult, but I'm starting to think we may
have entered the zone of diminishing returns.
...Robert
