Replacing openSUSE Leap

I have seen this proposed in the past for other distros, but the problems that come up are:
1. What does 'stabilized' mean? [You usually end up with people spending more time arguing over what that means and who gets to judge it than people actually testing for said 'stability'.]
2. Who is going to do the testing work to say something is stable?
3. What gets put into the pile of 'we care it is stable' and 'we don't care it is stable'?
4. Who is going to possibly backport fixes which need to be done versus boiling the ocean for a complete upgrade of a software stack.

Usually the discussions over this get incredibly heated because most of the items are subjective decision points. Most of those heated discussions come up in other areas, and when you have a small number of participants who have known each other for decades.. it is better to just avoid the unresolvable and present what might be generally accepted.

We had that model as openSUSE releases before Leap was based on SLE sources. The main trouble was that we wanted to avoid version upgrades for stability and that meant doing backports of fixes which takes quite some effort for 15000 packages.
There are also security fixes in newer versions that never get a CVE because nobody realized that "refactor foo" elimitated a severe vulnerability.

When Tumbleweed was first launched, I switched to it to have the new features & fixes out from upstream on the desktop in a timely manner. It was not uncommon to install packages you cared about compiled direct from upstream and if you run windows, you receive 3rd party updates direct from the developers without it causing continual chaos. I figured out how to gain the multi-media capabilities provided from 3rd party repositories that GKH had excluded and thought was not possible with Tumbleweed as he actually underestimated the features and flexibility of the SuSE package management system.

Previously I had to bastardise my base release by including a growing number of repositories, that included distro specific changes to upstream development. At times I was hit by regressions, discovered far too late; developers re-developing do have a tendency to deliver partial implementations and years later when their code eventaually reaches a distro they'll reject bug reports about something they thought they could drop and now the code is cold and unfamiliar, defective by design because it's something not used by developer peer groups. That lead to me having to replace hardware on 2 occasions.

Tumbleweed has no mechanism to say it's "stable" and snap shot worthy, freezing a state just creates a load of maintenance work deciding what fixes have to be patched into the base code. Nobody upstream is testing vs your distro, you'd be creating flag days for switches that needs lots of people to test. In my experience, Tumbleweed was NOT breaking the whole time, contrary to the fears of frozen release advocates. Packages have to be tested
against something for something to be included, so you have both upstream and a distro package contributor testing the update.

Slowroll is a far better idea, lets Tumbleweed users demand fixes if an engineer releases a broken package into it, while avoiding admin & work creation schemes of curating, what is supposed to be an improved code base by the work of developers and QA. Anybody who tracks Tumbleweed and uses the applications or uses upstream packages and reports bugs is contributing to the correctness of Slowroll.