Verification of product release requirements

A method relates to identifying, by a processing device, a bug ticket stored in a data record, wherein the bug ticket is associated with a patch comprising code to fix a bug described in the bug ticket, and wherein the bug ticket comprises a version flag indicating whether the bug ticket receives all of a plurality of acknowledgements, determining, in view of a value of the version flag, that the bug ticket does not include an acknowledgement required to place the patch into a production repository, determining, in view of a set of acknowledgement flags of the bug ticket, an entity responsible for providing the acknowledgement, and transmitting a notification to the entity, wherein the notification comprises a hyperlink linked to a user interface page to provide the acknowledgement by the entity.

TECHNICAL FIELD

This disclosure relates to software product development and, in particular, to facilitating the verification of software product release requirements.

BACKGROUND

Software is often developed through a series of different versions including major releases and minor releases. Major releases may include redesign of the architecture of the software, and significant changes to features and functionalities of the software. Minor releases, made more frequently than major releases, may include bug fixes and minor changes to certain existing features and functionalities. Between releases, users of the software may detect bugs in the software and may submit the bugs to the owner of the software to fix these bugs.

DETAILED DESCRIPTION

A patch may fix one or more bugs (or add one or more features). For simplicity of description, a bug or a feature is collectively referred to as a “bug” herein. A patch, when applied, may modify one or more lines of code in the software to fix the bug. A bug is commonly reported to the software owner by creating a ticket in a bug ticket system (referred to as a “bug ticket”). Before creating a patch to fix the bug, the bug ticket needs multiple approvals from various relevant entities. For example, the approvals may include an approval from a product manager who determines whether the bug fix (or added feature) meets customer's needs, an approval from a code development manager who determines whether a patch to fix the bug is technically feasible, and an approval from a quality assurance manager who determines whether the patch can be validated prior to the next release date. Each relevant entity may acknowledge the bug ticket by providing his or her approval or disapproval. When all entities approve the bug ticket, the patch has the permission to go into the software product in a next release. If any of the entities disapprove, the patch cannot enter software product.

Due to various reasons, these mandatory acknowledgements are often not provided by entities with authority in time during product planning phase. Without the necessary approvals (or disapproval) of a bug ticket, it is unclear whether the patch can be created and entered into a next release of the software.

Manual reminders, such as e-mail reminders, meetings, or personal face-to-face contacts are often used to remind entities that, for various reasons, fail to provide timely acknowledgements necessary to determine whether to accept a bug ticket into patch production. These manual reminders are prone to error and place a burden on the requester to take a necessary action in an allotted time frame. Manual reminders also add risk to the release date if timely acknowledgements are missing for specific bugs. For example, if the acknowledgements are not provided timely, there may be insufficient time to create a patch to fix the specific bugs, and the release of the software may be delayed due to technical limitation which requires all the bugs to be fully fixed.

Implementations of the present disclosure include systems and methods that may query a bug ticket system to identify bug tickets that have not acquired all of the requisite acknowledgements, determine the entities that neglect to provide the requisite acknowledgements, and generate and transmit a notification to the neglecting entities to request the missing acknowledgements. In one implementation, the query to the bug ticket system may specify certain criteria to filter the bug tickets that need acknowledgements. For example, in one implementation, the criteria may identify any bug tickets created during a certain time period.

Implementations of the present disclosure relate to identifying, by a processing device, a bug ticket stored in a data record, wherein the bug ticket is associated with a patch including code to fix a bug described in the bug ticket, and wherein the bug ticket comprises a version flag indicating whether the bug ticket receives all of a plurality of acknowledgements, determining, in view of a value of the version flag, that the bug ticket does not include an acknowledgement required to place the patch into a production repository, determining, in view of a set of acknowledgement flags of the bug ticket, an entity responsible for providing the acknowledgement, and transmitting a notification to the entity, wherein the notification comprises a hyperlink linked to a user interface page to provide the acknowledgement by the entity.

Implementations of the present disclosure relate to a system including a memory and a processing device, operatively coupled to the memory, the processing device to identify a bug ticket stored in a data record, wherein the bug ticket is associated with a patch including code to fix a bug described in the bug ticket, and wherein the bug ticket comprises a version flag indicating whether the bug ticket receives all of a plurality of acknowledgements, determine, in view of a value of the version flag, that the bug ticket does not include an acknowledgement required to place the patch into a production repository, determine, in view of a set of acknowledgement flags of the bug ticket, an entity responsible for providing the acknowledgement, and transmit a notification to the entity, wherein the notification comprises a hyperlink linked to a user interface page to provide the acknowledgement by the entity.

FIG. 1illustrates a processing system100to identify a bug ticket requiring an acknowledgement and to notify a responsible entity according to some implementations of the present disclosure. An entity can be one or more persons who have the responsibility to review certain aspect of the bug ticket and provide his or her opinion of the bug ticket. An acknowledgement can be an approval or a disapproval of the bug ticket. In one implementation, an entity may provide the acknowledgement by setting an acknowledgement flag associated with the bug ticket to a certain value. Referring toFIG. 1, the processing system100may include a processing device102(such as a central processing unit (CPU) with one or more processing cores) and a memory device104operatively coupled to the processing device102. The processing system100may be any type of computing devices including, but not limited to, a server computer. The memory device104may store executable instructions of software applications and the data associated with execution of the software applications. The processing device102coupled to the memory104may execute the instructions of the software applications.

In one implementation, the processing system100may include other resources (not shown) such as network cards to transmit and/or receive data with a network and storage devices that are mountable to the processing system100. An operating system106may serve as a software layer to the software applications with an abstract computer model to handle and manage all the resources of the processing system100.

In one implementation, the processing system100is coupled to a code repository110which may be a networked repository that is accessible by different open source developers. In one implementation, the code repository110may be a GIT version-controlled code repository. Open source developers may develop software modules of an open source product, and submit, by uploading, these modules to the code repository110. For example, an open source operating system (such as releases of Red Hat Enterprise Linux) includes a kernel that includes hundreds of modules such as kernel-based virtual machine (KVM) and the file system. Referring toFIG. 1, code repository110(e.g., a GIT repository used by open source code development) may include a data store as a centralized or distributed code depot to receive and store software modules uploaded by open source developers. For example, open source developers may upload software modules112A-112C to the code repository110. These software modules112A-112C constitute part of an open source software product. An organization (such as a corporation or a non-profit association) is responsible for collecting and integrating various software modules into the open source product and releases a tested version of the open source product as a current version of the open source product.

In the process of open source product development, the software modules112A-112C submitted by developers are reviewed and tested by other programmers either from a third party or from the organization that is responsible to release the product. During the review and testing process, these programmers may discover bugs and develop patches to software modules to these bugs. These patches, when applied to the associated software modules, may cause the insertion and/or deletion one or more lines of code in the associated software modules. For example, referring toFIG. 1, an open source programmer may have developed a first patch114A1to enhance certain functionality in the software module112A, and later, another open source developer (or the same open source developer) may develop a second patch114A2improving on the first patch114A1. Each of patches114A1,114A2may insert or delete one or more lines of code in the software module112A. Similarly, patch114B1may modify the code of software module112B. These patches114A1,114A2,114B1are stored in code depository110along with software modules112A,112B,112C.

A patch to the software module is typically used to fix a bug or enhance a feature. To add a patch to the software module, a bug ticket126is created in the bugzilla124. The bugzilla124is a data record to store a record of a proposed bug fix and its status, including information about each proposed bug fix. In one implementation, bug ticket126as a data entry in bugzilla124may include a number of acknowledgement flags indicating whether the proposed bug fix has received the necessary acknowledgements (approval or disapproval). For example, the bug ticket126may include a first acknowledgement flag indicating whether the program manager116has acknowledged patch114A2, a second acknowledgement flag indicating whether the code development manager118has acknowledged patch114A2, and a third acknowledgement flag indicating whether the quality assurance manager120has acknowledged patch114A2.

In one implementation, each acknowledgement flag includes one or more values representing whether an entity responsible for the acknowledgement has checked the flag. In one implementation, for example, an acknowledgement flag value of zero (0) may indicate that the entity has not acknowledged the bug ticket126, a value of one (+1) may indicate that the entity has acknowledged and approved the bug ticket126, and a value of negative one (−1) may indicate that the entity has acknowledged and disapproved the bug ticket126.

In one implementation, bug ticket126may further include a version flag to indicate an overall acknowledgement status of the bug ticket. The version flag may be set to according to values of the first to third acknowledgement flags to indicate whether the bug ticket has received all the necessary acknowledgements. For example, the version flag may be set to one (+1) if the bug ticket126receives all three acknowledgements, and set to zero if the bug ticket126does not receive any of the three acknowledgements. In one implementation, the version flag may be updated when a value of a respective acknowledgement flag is updated. For example, the value of the version flag may be calculated as a combination of the values of the first to third acknowledgement flags (e.g., first acknowledgement flag∥second acknowledgement flag∥third acknowledgement flag; wherein “∥” represents the AND operator). As such, the value of the version flag, by itself, may determine whether a bug ticket has all the necessary acknowledgements.

A bug ticket126can be created in the bugzilla124in response to a request to change certain behavior of a software module. After the bug ticket126receives all of the necessary acknowledgements (e.g., the first to third acknowledgement flags are checked with approval by entities with authority), a programmer may be assigned to create a patch for the bug ticket. Under certain situations (e.g., at an urgent request), a developer may create a patch for a bug ticket prior to the bug ticket receiving all of the necessary acknowledgements. But, the patch associated with a bug ticket that has not been approved still cannot be entered into the software production.

Thus, a bug ticket126needs to undergo a review and approval process before a patch associated with the bug ticket126can be submitted to an authoritative repository storing approved patches that can be integrated into the software product. In one implementation, as discussed above, a patch114A2may be submitted to a staging area122which is part of the code repository where the patch undergoes the review and approval process before entering into production. The submitted patch114A2may be associated with bug ticket126before the bug ticket126receives all of the necessary acknowledgements. An acknowledgement by an entity means that the entity has reviewed and provided an opinion with respect to the bug ticket126. For example, bug ticket126may require acknowledgements from a product manager, a code development manager, and a quality assurance manager. Each entity may be one or more persons that have the authority to acknowledge and approve (or disapprove) entering the patch into software production. When the bug ticket126receives all three acknowledgements and approvals, the patch114A2associated with the bug ticket126may pass its version review and may be submitted to production. If, however, any of the requisite entities disapprove the bug ticket126, the patch114A2cannot enter into software production. In one implementation, the developer may commit patch114A2to the staging area112before the bug ticket126receives the necessary acknowledgements. The developer may record a hyperlink in the commit message of patch114A2to link the pending patch114A2to the bug ticket126in the bugzilla124. This hyperlink in the commit message of patch114A2enables the detection of which pending patch associated with a bug ticket that does not have all of the necessary acknowledgements.

In one implementation, to ensure that each entity timely reviews and acknowledges the bug ticket126stored in the bugzilla124, processing system100includes a bug ticket monitor application108, executed on processing device102, to identify all bug tickets in the bugzilla124that have not received all necessary acknowledgements and identify the entities associated with and responsible for providing the missing acknowledgements. The bug ticket monitor application108may generate and transmit a customized notification to each of these entities to request the missing acknowledgements.

In one implementation, the bug tickets are identified according to certain criteria. For example, the bug tickets monitor application108may identify a patch that has been uploaded to the staging area122during a specific period of time (e.g., last twenty four hours or uploaded since last release of the software product) associated with a bug ticket with at least one missing acknowledgement. The bug ticket monitor application108may generate and transmit a notification to responsible entities to request the missing acknowledgements. For example, as shown inFIG. 1, if the bug ticket monitor application108identifies patch114A2including a hyperlink to a bug ticket having missing acknowledgements from product manager116, development lead118, and quality assurance120, the bug ticket monitor application108generates e-mail notifications to product manager116, development lead118, and quality assurance120to request their acknowledgements of the bug ticket. The e-mail notification, targeting the entity responsible for the acknowledgement, may include a link to a web page of the bug ticket on which the responsible entities may provide the necessary acknowledgement. For example, the web page may include an actionable interface element (e.g., checkbox including a set of values to select) associated with the necessary acknowledgement. The entity may activate the actionable element to provide the necessary acknowledgement. For example, the entity may select a value of one (+1) to indicate approval and a value of negative one (−1) to indicate disapproval. Because of the targeted notification, entities that are not linked to the patch are not notified by the bug ticket monitor application108.

The code repository110as shown inFIG. 1may be implemented as a suitable type of version-controlled code repository. In one implementation, the version-controlled code repository may be a GIT type code repository that includes a Gerrit code review tool. The bug ticket monitor application108and the staging area122are implemented using the Gerrit code review tool. Thus, changes to the software product undergo the review and approval process before entering into the software production.

FIG. 2illustrates a bug ticket acknowledgment system according to an implementation of the present disclosure. Referring toFIG. 2, the bug ticket acknowledgement system200includes a bugzilla206and a code review system220. The code review system220may be a GIT version-controlled code repository including a staging area202and an authoritative repository204. The authoritative repository204may store software module218as part of an open source product to be released to the public. During testing and reviewing process, programmers may submit patches208,210to fix certain bugs uncovered by the programmers. In one implementation, programmers may submit, by a commit command, patches208,210to the staging area202to wait for the necessary acknowledgements and approvals before they can be submitted to the authoritative repository204(or the production repository) and integrated into software module218.

In one implementation, the bug ticket acknowledgement system200may provide a web-based user interface (not shown) for parties to submit bug tickets208C,210C to the bugzilla206. When submitting a bug ticket to the bugzilla206, the bug ticket creator may use the user interface to specify one or more entities whose approvals are needed before a patch associated with the bug ticket can be submitted to the authoritative repository204. In an implementation, if the creator does not specify the entities to approve, the bug ticket, by default, requires acknowledgements and approval from a set of default entities (e.g., a product manager214A,216A, a code development manager214B,216B, and a quality assurance manager214C,216C).

In one implementation, the information stored in the bug tickets208A,210A may further include description of a bug and the fix to the bug. This description may help product manages214A,216A, code development managers214B,216B, and quality assurance managers214C,216C to understand the issues and make informed decisions.

In one implementation, the staging area202and the authoritative repository204are part of a GIT version-controlled code repository in which patches208,210are submitted to the staging area202via a commit command. When the patch owner commits the patch to the staging area202, the patch owner is prompted via the user interface to enter information about the patch in a commit message. For example, as shown inFIG. 2, patches208,210committed to the staging area202may be associated with commit messages208A,210A, respectively.

In one implementation, a patch210may be merged into the staging area202before the bug ticket210C associated with the patch210has received all of the necessary acknowledgements and may not be submitted to the authoritative repository204. In one implementation, the developer of patch210may record a bug identifier in the commit message210A for the patch210. The bug identifier in the commit message210A may include a hyperlink to link the bug identifier to the bug ticket210C stored in the bugzilla206.

As previously discussed, the bug tickets208C,210C may include acknowledgment flags whose values indicate whether a bug ticket has received specific acknowledgement and a version flag whose value indicates whether the bug ticket receives all of the necessary acknowledgements. A patch may be submitted to the authoritative repository if the bug ticket associated with the patch receives all of the acknowledgements indicating an approval.

As discussed before, entities that are responsible for acknowledgements often fail to provide timely acknowledgements. To address this issue, in one implementation, the bug ticket acknowledgement system200may include a bug ticket monitor application108as shown inFIG. 1to monitor patches that had been submitted to the staging area202during a pre-determined period of time (e.g., with the last twenty four hours or since last release of the software product). The bug ticket monitor application108may identify these patches committed during the pre-determined period of time by checking the commit time of the respective patches. In response to identifying the set of patches that have been committed to the staging area during the pre-determined period, the bug ticket monitor application108may identify the bugs contained in the commit messages208A,210A associated with the set of patches208,210. For each of the patches, the bug ticket monitor application108may determine whether the patch is associated with a bug ticket that does not include any of the requisite acknowledgements. In one implementation, the bug ticket monitor application108may trace the hyperlink in the commit message to the associated bug ticket and make the determination based on the value of the version flag in the bug ticket. For example, if the version flag is set, the bug ticket monitor application108may determine that the associated bug ticket has received the mandatory acknowledgements. If the version flag is not set yet, the bug ticket monitor application108may determine that there is at least one missing acknowledgement and further check each of the acknowledgement flags of the associated bug ticket to determine which entity failed to provide an acknowledgement.

In response to determining the entities that failed to provide an acknowledgement, the bug ticket monitor application108may generate and transmit a notification to the entity to inform the entity about the missing acknowledgement. In one implementation, the notification may be an e-mail that includes a hyperlink to a user interface web page via which the entity may provide an acknowledgement. In another implementation, the notification may be a text message including a response pathway (e.g., a phone number) through which the entity may provide the mandatory acknowledgement. In yet another implementation, the notification may include both an e-mail and a text message to the entity to provide a multi-mode notification to the entity.

In one implementation, the bug ticket monitor application108may periodically query the bugzilla206to determine whether any bug tickets miss acknowledgements. As discussed before, each bug ticket in the bugzilla206may include version flags and acknowledgement flags to indicate the status of acknowledgements. For example, the bug ticket monitor application108may check the version flag in a bug ticket208C,210C to determine whether the bug ticket miss any acknowledgements. If the value of the version flag indicates that the bug ticket has received all three acknowledgements, the bug ticket monitor application108may check next data entry. If, however, the value of the version flag indicates that the bug ticket misses at least one acknowledgement, the bug ticket monitor application108may further check individual acknowledgement flags of the bug ticket to determine which entity fails to acknowledge. The bug ticket monitor application108may then generate and transmit a notification to the entity to inform about the missing acknowledgement.

FIG. 3is a flow diagram illustrating a method300to identify unacknowledged bug tickets and notify the responsible entities according to some implementations of the disclosure. The method300may be performed by processing logic that comprises hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device to perform hardware simulation), or a combination thereof.

Referring toFIG. 3, at302, the processing logic may start. At304, the processing logic retrieves and identifies a bug ticket stored in a data record (e.g., a bugzilla). As discussed above, the bug ticket may have been created in response to discovering a bug in a software product. The bug ticket may be associated with a patch to fix the bug. In one implementation, the bug ticket may include a version flag and a number of acknowledgement flags. The each acknowledgement flag may include a value indicating whether the bug ticket has received the acknowledgement (approval or disapproval) from a responsible entity, and the version flag may include a value indicating whether the bug ticket receives all of the necessary acknowledgement flags.

At306, the processing logic may determine from a value of the version flag of the bug ticket that the bug ticket does not include a mandatory acknowledgement from at a responsible entity. For example, the value of the version flag of this bug ticket may be zero “0” indicating that the version flag is not set (i.e., at least one entity failed to provide a mandatory acknowledgement).

At308, the processing logic determines which entity failed to provide the mandatory acknowledgement. The processing logic may check a set of acknowledgement flags that each corresponds to one type of acknowledgement responsible by one respective entity. The type of acknowledgement may include, for example, a product manager acknowledgement, a development manager acknowledgement, or a quality assurance manager acknowledgement. The value of an acknowledgement flag can indicate “acknowledged with approval,” “acknowledged with disapproval,” and “not acknowledged.” The processing logic may determine the entities that have not acknowledged the bug ticket in the data record.

At310, the processing logic transmits a notification to the entity that failed to provide the mandatory acknowledgement to request that the entity to provide the acknowledgement. In one implementation, the notification is a customized message directed to the particular entity with respect to the particular acknowledgement that the entity is responsible for. Further, the notification may include a hyperlink to a web page that provides an interface configured to provide the requisite acknowledgement to the bug ticket, thus facilitating the acknowledgement process.

In one implementation, the processing logic may cycle through all bug ticket in the data record to identify those that have missing acknowledgements, and generate and transmit customized notifications to entities responsible for the missing acknowledgements.

Although the notification of missing acknowledgements is described in the context of but tickets to software code, implementations of present disclosure may be applied to other types of documents in code development that require acknowledgements. For example, the documents may include an Errata document (a list of all bugs that have been fixed in a software release) and the processing logic may remind the owner of the software product to update the Errata document after the code has been updated.

The computer system400may further include a network interface device422. The computer system400also may include a video display unit410(e.g., a liquid crystal display (LCD), a cathode ray tube (CRT), or a touch screen), an alphanumeric input device412(e.g., a keyboard), a cursor control device414(e.g., a mouse), and a signal generation device420(e.g., a speaker).

The data storage device418may include a computer-readable storage medium424on which is stored one or more sets of instructions426(e.g., software) embodying any one or more of the methodologies or functions described herein (e.g., the bug ticket monitor application108). The instructions426may also reside, completely or at least partially, within the main memory404and/or within the processor402during execution thereof by the computer system400, the main memory404and the processor402also constituting computer-readable storage media. The instructions426may further be transmitted or received over a network474via the network interface device422.