Drawing lessons from fatal SELinux bug #1054350

Dominick Grift dominick.grift at gmail.com
Fri Jan 24 20:06:29 UTC 2014

On Fri, 2014-01-24 at 11:14 -0800, Adam Williamson wrote:
> On Fri, 2014-01-24 at 19:26 +0100, Michael Schwendt wrote:

> I think that's being unnecessarily harsh on the testers. It's not at all
> obvious to anyone that you ought to test update/install of another
> package in order to validate an update to selinux-policy-targeted .
> Hell, I don't do that.

Agreed, The testers did not fail. Their issues were solved. They could
not have found this issue in reason. There was no change log entry for
it, and even if there was they would still would need to be able trace
the bug to SELinux.

The commit that caused this grief, was meant for rawhide but it ended up
in the wrong branch. (too many branches, too high volume fixes, Too much
rushing. Routine can be a killer)

Only the people that know this matter could have prevented it in reason,
anything else would have been just luck in my opinion.

In my view there are two issues that need to be addressed.

- Take your time, think twice before you commit and double check what
you commit. Do not let routine get the upper hand. Give all your changes
the attention they deserve.

- Coordinate with your team mates. Proof read each others commits (if
only skim over them)

If a team proof reads each others commits then this could have been
prevented in reason. Sure it is a structural investment but it pay's off
and its not as bad as it sounds. Five minutes daily?

More information about the devel mailing list