If the release engineer can't find the cause quickly, the release engineer is then empowered to find a software engineer to assist him in tracking down the regression. Once the cause of the regression has been found, the release engineer and the software engineer find an owner for the bug and evaluate how long it will take to fix the problem. The estimated time to fix the bug is communicated to all developers. If a fix for the regression is ready, then the fix is checked into the tree and the verification builds are rebuilt. When the builds are complete, the builds are then re-tested to verify the fix and ensure that another regression hasn't been introduced.
Developers are free to commit source code changes to the revision control system.
In some cases there has been sufficient progress in the bug investigation and the tree will re-open. In other cases it is determined that the regression have a workaround or are not critical features and the tree will re-open. Occasionally the release engineer in charge of the verification will grant exceptions to this rule. In most cases, we let people commit changes into the source tree that are not a part of the primary make process. The verification process effectively prevents a large number of engineers from being able to commit changes to the source code.