Stabilizing a package is a serious thing

I recently joined the x86 project, and I'm helping with marking packages as stable on that architecture.

Even in this short period of time, I've hit several things that prevented or delayed a package from becoming stable. I think it's a good idea to warn people before rather than after, so if you want your package to become stable, please watch out for any of these:

• unstable dependencies; just file bugs for these first
• failing tests; you should be running with FEATURES="test" all the time to catch these
• upstream considering the version experimental; why should we consider it stable then? There are exceptions to this rule however if older versions are unmaintained.
• open bugs for the package
• repoman warnings for the package, or QA concerns on manual ebuild inspection (like not calling die on emake failure)
• requiring the user to do manual configuration that could be instead performed automatically that if not done prevents the package from working completely

Additional note: if you know any issues about the package that might raise concerns of any of the arch teams, indicate so in the stabilization bug report.

One more note: does every minor version bump need to get stabilized?