I think that you can, in that you can control what gets accepted into the release. But it would be more effort on your part to verify that maintainers are actually meeting their obligations. I think that Debian’s use of its own bug tracker for all its packages is an aide to this for them. They can easily check how many open tickets a package has and what type they are. It’s possible that some of the work coming out of the current quality assurance effort might provide something that can be used here. For example, the CI badge functionality can be used to automatically check that a package has CI, and is passing that CI, before it gets accepted into the LTS release.
But as you say, ultimately with the current nature of the ROS community, trusting the maintainers is necessary.
I don’t think the purpose of Debian’s testing branch existing for two years before it becomes stable is to have two years of testing a single version of the package. It provides enough time for users to work with software that isn’t blowing up but provides up-to-date features with further updates possible and gives them time to update their own stuff to match.
Maintainers upating their packages in an LTS release should have very very strict requirements on what is accepted (bug fixes only being an obvious one) to ensure that the LTS remains the same stable target it is at the start.
I think that this is in conflict with the goal of the LTS release being a stable platform on which products can be built. I think it’s also part of why Debian has separate unstable and testing rolling releases: testing is considered usable for non-critical applications (I know many people who use testing for their daily-use computer, but only one probably insane person who uses unstable for daily use) so it gets the package out there as you want, without making the stable release risky.
I strongly agree with failing early. Users of the next release need as much advance notice as possible that something they depend on is going to disappear so they can plan and enact changes in their own stuff.
I would prefer the opposite approach: the rolling release should be on-going forever, and the LTS release should be a snapshot of it at a point in time. I do not see a benefit to restarting the rolling release every time a new LTS release is made. Is the intention here that testing for the LTS release is done separately from the rolling release and the rolling release becomes a new-features branch of the LTS release?
I think that much of this discussion is being driven by an unstated assumption about what the LTS release is intended to be. I would like the OSRF to make that assumption clear so we know what the goal is. Is the LTS release intended to be a stable platform for products to be built on and for use in critical applications, or is it a snapshot of package versions at a point in time that may be updated as package maintainers feel like it?
Put another way, does the OSRF see its position as like the Linux kernel developers, who release new kernels regularly but do not pay much attention to the testing necessary to ensure usability in critical applications and leave the production of releases for critical applications to others (the Debians and Red Hats), or does the OSRF see itself as like the Debian Foundation, providing a well-tested base on which applications can be built?
I’m not criticising either position because both are perfectly valid, it just needs to be clear. It will impact the release process requirements, how many resources the OSRF needs to invest, and what companies would then expect from a release provided by the OSRF. I hope to one day see a Red Hat emerge for ROS so if the OSRF does not want to be doing this work I do not think it is a disaster for ROS.