Another factor to consider is that the Release Candidates should be widely-publicized as stable, near final, with testing encouraged.
I wasn't particularly focussed on the CC release process, but my impression was there were a few mentions from official sources of the RC1, RC2, and without a bold proclamation of what's supposed to be working.
That made it hard for me to decide "when to jump in" and try out the release candidates. Our release notes need to ask people to test, and give them reasons to do so.
I would advocate that our Release Notes for RC1 &c have the form:
- The LEDE Project provides a powerful and stable operating system replacement for routers and embedded devices. For more information, see https://lede-project.org/about
- This is Release Candidate #1 (RC1) for our upcoming "LEDE XX.YY" release. It contains the following new features:
- Feature A
- Feature B
- ... etc...
- We believe the software is stable, and can be used widely, although still in test situations.
- If no bugs were found, we would ship this version. (Of course, there probably will be bugs in this release candidate, so...)
- We plan to make an additional N Release Candidate releases, and ship on or around ddMMMyyyy
- No new devices (beyond those already in the ToH) will be added/supported in this release
- Please help us test!
- [And finally, no talk about the new development/trunk release. We don't want potential testers distracted by shiny new toys that won't appear for months.]