Unfixed bugs because the release needs to be pushed out of the door before a bug fix is in and tested, just because it is time to release. As opposed to delaying the release by however long it takes in order to incorporate an important bug fix and not release a buggy version.

Instead of fixing four release dates a year, take things one step at a time. Once a release is out of the door, fix a future feature freeze day. After that has passed, fix a release date. Any feature patches that arrive after the freeze date go into the next release, unless they're really important, in which case the release gets pushed back by however long it takes to incorporate. The release happens whenever the code is sufficiently bug-free to satisfy the project manager(s). Yes, you need to draw the line somewhere and say this patch goes in and that one doesn't, but that's just a management issue. It means you make the cut based on a technical evaluation, which is surely superior to making the decision based on the time that has passed since a certain Middle-Eastern man was (or was not, whichever your persuasion may be) born.

Besides, "sending in their patches early" doesn't really happen very much, does it? Most patches are submitted just before the code freeze date. As a project manager you need to deal with that issue.

I personally really like the new Linux kernel method of having extremely short windows between a project release and a feature freeze (currently two weeks), but there are bound to be different time scales which are ideal for different projects.