Whenever a patch is created, it is placed in an internal database where we can all track the status and progress of the patch. Additionally, all interested parties, like patch requestors and test, will have an automatic hold on the patch preventing its release to SunSolve. The patch requestor, as officially defined by the tools, is whomever the engineer specified as the requestor in their patch RTI (Request to Integrate). This should be whomever is asking them to backport their fix to Solaris 10, and at this point it must be an internal person. Many engineers will use themselves as the requestor since they are doing the backport on behalf of a customer.
All Solaris patches are delivered to an internal group called Patch System Test (PST) where they do basic regression testing of the patch and test applying patches on systems with popular enterprise applications. PST has a one week test schedule, so if the patches are delivered *just* after a cycle has started, they will have to wait until the next cycle begins so it may take a patch up to two weeks just to get through testing. If PST is satisfied by the patch, they will release their hold on it.
Each developer & patch requestor is then responsible to do unit testing with each patch, to make sure the bugs it is supposed to be fixing are actually fixed, that all dependencies of the patch are actually correct, and that the README content is accurate. This is where things sometimes slow down in the cycle if engineers are on vacation or don't understand that it is indeed their responsibility to do this. Fortunately, that does not happen often, and is normally quickly caught by an engineer covering an escalation for a customer or someone else desperate for the patch.
As soon as all of the holds are released, the patch is pushed out to SunSolve within 24 hours by an automated system. If there is an urgent need, the patchmanager, with the proper escalation, can override individual holds during special circumstances to get a patch out even faster.
Posts
