HEADLINE: Day(s) old sid as a rolling distro DESCRIPTION: I think I represent a number of users. We want to use unstable as a rolling distribution, but we don

HEADLINE: Day(s) old sid as a rolling distro DESCRIPTION: I think I represent a number of users. We want to use unstable as a rolling distribution, but we don't want to run into every edge case. Testing doesn't update fast enough and doesn't have as good of security. There's no middle ground between absolute bleeding edge and the too conservative testing. I used to use unstable but there's that annoying race condition where I could upgrade at the exact wrong time when brand new (broken) package versions were uploaded and not enough time has passed for even the first round of bugs. I'd like a day safety buffer so apt-listbugs has a chance to warn me about catastrophic bugs. Setting up a true rolling distribution may be too much work for Debian. Actual Debian developers will be running unstable. It would be nice if there was a middle ground for non-Debian developers who want a rolling distribution but don't want to get hit by every edge case in sid. I think a nice compromise would be to cache the sid packages for a day (or two) and set that up as another branch. A full day of possible bug reports from people on bleeding edge sid would give us a chance at missing the catastrophic edge cases while still being very current. I think this could encourage more Debian developers. If I wanted to join Debian as a DD, I would need to have an unstable installation somewhere. It wouldn't be my daily driver because I don't want to run into those breaking edge cases. If my daily driver was day old sid, I could have another machine / VM that runs sid and would almost be identical to what my daily driver is running. It's not like testing where packages could be entirely different due to the delay in migrating. Unlike testing, day old sid would migrate all packages even if there are release critical bugs. There would be no waiting period beyond the strict day limit. If there is a catastrophic edge case, people already on day old sid using apt-listbugs would be able to avoid it. New installations would hit it but you could warn users (see below). If you make apt-listchanges and apt-listbugs as required packages for day old sid, then people could be informed about what broke on the previous day. It would be nice to integrate apt-listbugs into an installer for day old sid and fetch the latest critical or high priority bugs before the installation. A new user could then decide if that's a good day to install. Or you could have a simple website that says here's the day old sid installer and these packages currently have critical or high priority bugs. If you would install those packages, maybe wait another day or two for it to settle down. Maybe day old sid is too close. Perhaps 2 day sid or 3 day old sid? I don't feel that testing fills this role already because testing waits for 2-10 days and won't update if there are release critical bugs. I'm fine with something closer to bleeding edge sid, but I'd really like to allow a few days for the bleeding edge users to report bugs so I can decide whether to upgrade. I don't have an expectation that day(s) old sid is more stable than testing or less unstable than sid. All it provides is a buffer so I can get bug reports and make my decision about whether to upgrade. DISTRIBUTION: day old sid.