On Wed, Nov 2, 2016 at 10:41 AM, Christian Stadelmann <genodeftest@xxxxxxxxxxxxxxxxx> wrote: > 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. They fix some of the issues but can often cause just as many more. For this to be effective we need also a decent CI platform to run automated tests against API/ABIs and other such things. The auto build also doesn't have the knowledge to deal with things like patches IE does the patch need to be rebased or dropped due to upstream status (is the patch Fedora specific, was it pulled from upstream awaiting a new release etc). > * mainainer response: Many packages have only one effective maintainer or none at all. Solution: Not easy, since we don't have enough maintainers There's ways to address this, but also a lot of the CVEs for packages are local exploit only and a lot of the packages are also corner cases. In the case of something that's remotely exploitable there's often people around with the ability to deal with any of the packages and people (I regularly assist) are able to assist. > * 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. That doesn't stop an update from being submitted, updates once they are submitted are only locked when they are being actively processed and pushed out as part of an updates push. There were some bugs in bodhi for this but they are now fixed. > * testing: more people could contribute to test packages This is a problem for all updates! And even when people are testing (all my systems always have updates-testing enabled) it requires them to provide active feedback through karma for their testing to be effective. > * 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. It's also something completely out of our control, mirrors are in control and pull from the primary mirrors, we have no functionality to push to them. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
