We as a project have gone back and forth on the topic of quality and the notion of a releasable trunk for quite a few years. If people are interested, I'd like to rekindle this discussion a bit and see if we're happy with where we are as a project or if we think there's steps we should take to change the quality bar going forward. The following questions have been rattling around for me for awhile:
1. How do we define what "releasable trunk" means? All reviewed by M committers? Passing N% of tests? Passing all tests plus some other metrics (manual testing, raising the number of reviewers, test coverage, usage in dev or QA environments, etc)? Something else entirely? 2. With a definition settled upon in #1, what steps, if any, do we need to take to get from where we are to having *and keeping* that releasable trunk? Anything to codify there? 3. What are the benefits of having a releasable trunk as defined here? What are the costs? Is it worth pursuing? What are the alternatives (for instance: a freeze before a release + stabilization focus by the community i.e. 4.0 push or the tock in tick-tock)? Given the large volumes of work coming down the pike with CEP's, this seems like a good time to at least check in on this topic as a community. Full disclosure: running face-first into 60+ failing tests on trunk when going through the commit process for denylisting this week brought this topic back up for me (reminds me of when I went to merge CDC back in 3.6 and those test failures riled me up... I sense a pattern ;)) Looking forward to hearing what people think. ~Josh
