On Wed, Jan 17, 2024 at 08:32:15AM +0100, Patrick Steinhardt wrote: > I would like to avoid cases like this by laying out a plan for when > experimental features become the new default. It could be as simple as > "Let's wait N releases and then mark it stable". But having something > and documenting such a plan in our code makes it a lot more actionable > to promote those features to become stable eventually. Fair point. I think that these have been mostly ad-hoc. Unfortunately, when folks leave the project or change their attention to working on a different feature, things that were left in feature.experimental may be forgotten about. When this inevitably happens, it would be nice to have a written record (either in the repository, or here on the mailing list) so that other folks can take up the mantle and graduate those feature(s) as appropriate. > I know that this is not in any way specific to your patch, but I thought > this was a good opportunity to start this discussion. If we can agree on > my opinion then it would be great to add a comment to the experimental > feature to explain such an exit criterion. I don't have a ton to add here for a graduation plan other than it would be nice to enable it eventually, likely after a few releases without any show-stopping bug reports. > Other than that this patch looks good to me, thanks! Thanks again for the review! Thanks, Taylor