Re: Pondering security update time frames

1. and 2.: Yes, it often takes at least 3 days for security critical updates in important packages (e.g. kernel update to 4.8.3) to land. I think the real challenge here is to continue shipping quality software while reducing time to ship. Scratch builds and release-monitoring.org (Anitya) have improved this a lot, effectively providing finished update builds within <24 hours after upstream update release – at least for some packages with upstream tracked there. Parallel to bodhi/koji preparing the update the maintainer can review code and have the update ready to submit to updates-testing. Some reasons why updates take some time to be shipped to the user, plus some solutions or open questions: * time goes by before maintainer and build system know there is an update. Solution: release-monitoring.org. Packages just have to use it. * building the package takes some time. Solution: Auto-build feature. Package maintainers just have to use it. Doesn't work well with all packages. * mainainer response: Many packages have only one effective maintainer or none at all. Solution: Not easy, since we don't have enough maintainers * when submitting a build to updates-testing or updates, the repo quite often is in "locked" state causing a delay of e.g. 10 hours. This should be fixed. * testing: more people could contribute to test packages * mirrors are often outdated. I've seen delays of more than 2 days earlier this year. From my subjective perspective this has improved, but getting updates to all mirrors in <24 hours is probably too hard to do.