Now that Drupal 8 is in release candidate phase, the goal is to get out of release candidate phase and onto release as quickly as possible. That means we'll be locking down the patches committed to 8.0.x fairly significantly, so as not to potentially disrupt stability.

What patches can get committed now?

This is a complete list of the issues that are allowed in Drupal 8 before 8.0.0:

• critical issues: Issues that are (legitimately ;)) marked critical are the first priority to resolve ASAP during release candidate. We can and will roll back any other types of patches if they introduce critical issues, or impact our ability to fix a critical issue. Note that we may choose to defer critical fixes to 8.0.x/8.1.x if the impact vs. disruption ratio risks postponing release.
• rc eligible: This tag is for non-invasive patches which solely make coding standards, testing, and docs improvements. Anyone may add (or triage) this tag.
• rc target: These are a handful of exceptions to the above; generally major issues with both a high impact and low disruption that would be much better/easier to get in before release than after. Only core committers should set this tag.

And... that's it! :) If you feel your non-critical, non-docs/coding standards/tests patch should be considered for an exception to be committed during RC use the rc target triage tag to alert core committers to it. They can then review and choose to switch to rc target or not. In order to aid committers in making that decision, a good issue summary containing rc target justification will really help. A good issue summary is of course also important on rc eligible issues.

Make sure to read Allowed changes during the Drupal 8 release cycle and in particular the section on release candidates for more detailed information.

How long does this "commit freeze" go on?

Until Drupal 8.0.0's release. That could be a minimum of 4 weeks (RCs are released every two weeks, and we'll need at least two of them [including a 3 week notice on release date] to tell if we're release-ready), or a maximum of $your_bet_here. ;)

Over at Release branches for core patch releases/release candidates we're discussing ways we can potentially commit RTBC patches during RC without disrupting our ability to ship (think feature branches 0.1). Thoughts over there would be welcome.