Content

• Case Study
• Requirements
• User's View

Case Study

Let's suppose you have two branches in a CVS repository (

and

). Normal development takes place in

and

branch is for stabilization before some release.

Problematic situations:

1. Bug is fixed only in main-trunk because it is too risky to fix it in stabilization branch.
2. Bug is fixed only in stabilization branch because fix is needed for the release, but for the next release more sophisticated fix will be developed.
3. Sustaining group wants to create patch for some release. So, they need to modify bugs for the release they are patching.
4. User wants to list all bugs in the release he/she have installed on his/her computer.

Requirements

Following requirements should be fulfilled to solve problems mentioned above:

• Attributes of bugs can differ in different branches.
• New branch can be created for some product from another branch.
• Bug can be modified in given branch.
• Bug can be modified in several branches at once.
• Bug can be entered into given branch.
• Bug can be entered into several branches at once.
• New branch of bug can be created.
• User can find bugs in specified branch.

Bugs can have different status and comments in different branches. Look at the situations one and two from the case study. For example in the second situation the bug will be marked as FIXED in the stabilization branch and left as ASSIGNED or even NEW in the main-trunk where also comment about necessary changes will be added.

When new branch is created in CVS repository it is sometimes a good idea to branch bugs according to the CVS branch. For example in the case study we are interested not only in bugs that are in stabilization branch (these bugs will be in the upcoming release) but also in the main-trunk (these bugs will be in next releases).

This requirement is connected with the first requirement. The user should have possibility to see and modify attributes in the branch he/she is interested. He/she should be able to switch from one branch of the bug to another easily.

The most common situation in the case study is that the bug is fixed in both branches at once. So, there should be possibility to manipulate with attributes in more branches at once. For example when the bug is fixed in both main-trunk and stabilization branches the developer should be able to select both branches and change their status at once.

When a branch exists some time it is natural that bugs that appear only in this branch are found.

It is impossible to know about all bugs in the current build. New bugs that appear in several branches are found quite often. Therefore it is important to be able to enter new bug into several branches at once. Care should be taken of branches new bug should be entered into. In open-source projects we cannot rely on a good will of the external user to try whether this bug appears in other branches. Some rules have to be established about branches that probably contain the new bug.

Sometimes can happen that bug was entered into more specific branch that it should have been entered. In such situations it should be possible to branch just one bug report.

Ability to list bugs in given branch is very important for almost al groups: users, QA engineers, developers, managers etc. Users should be able to find all open bugs in their installed version. Managers are interested in fixed bugs for particular patch etc.

Users View

User's view of the bug-branching depends on the depth of its support.

Light support

• Branch corresponds to the Version (or maybe to the combination of few attributes like Version and Target-milestone).
• Each branch of a bug has its own bug number.
• One branch of the same bug is associated with other branches through field like Other Branches similar to Depends on field.
• When a new branch is created for some product from a given branch, attributes of bugs in the given branch are copied into new bug reports and Other branches fields are modified to show up-to-date information. Maybe additional rules should be specified what should happen with both branches (e.g. Target-milestone should be set to something etc.)
• Bug can be modified in given branch by editing bug with Version set to specified branch.
• "Modify several branches" link is part of the page displaying attributes of bugs. This link moves user to the "Change several bugs at once" page with all branches of this bug shown. User can select which branches he/she wants to modify.
• Bug can be entered into some branch by setting correct Version.
• Attempt to enter bug into several branches means that someone have found a bug that appeared in the product before the branch was created. So, the user have to specify only one Version (the one before branching) and the bug will be entered into all branches created from this Version. This means that somewhere in the Scarab have to be stored rules (maintained by administrator) that determines the branches the entered bug should belong to. Maybe additional rules should specify how should be set some attributes (e.g. Target-milestone) in branches.
• User can create new branch of some bug by duplicating existing bug report (and setting correct Version).
• User can find bugs in the given branch by submitting query with Version set to the name of the branch.

Some kind of compromise between the light and wide support.